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(54) A semiconductor memory card, playback apparatus, recording apparatus, playback method, 
recording method, and computer- readable recording medium 



(57) A plurality of audio object (AOB) files and a plu- 
rality of picture object (POB) files are stored. Default 
Playlist Information and sets of Playlist Information each 
show an order in which AOBs stored in the plurality of 
AOB files are to be reproduced. The DPLGI includes 
DPLI_POB_SRPs that specify at least one POB to be 
displayed during the playback period of AOBs indicated 
by the playback order given in the Default Playlist Infor- 
mation. The TKGI includes TKI_POB_SRPs that spec- 
ify at least one POB to be displayed only during the 
playback period of a particular AOB out of the AOBs 
indicated by the playback order given in the Default 
Playlist Information. 
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Description 

[0001] This application is based on applications 
Nos. H1 1-149893, H1 1-236724, and H1 1-372604 filed 
in Japan, the contents of which is hereby incorporated 5 
by reference. 

BACKGROUND OF THE INVENTION 

1, Field ofthe Invention 

[0002] The present invention relates to a semicon- 
ductor memory card that stores audio data, still image 
data and control data, and to a playback apparatus, 
recording apparatus, playback method, recording 
method, and computer-readable recording medium 
relating to such a semiconductor memory card. In par- 
ticular, the present invention relates to improved storage 
of audio data, image data and control data distributed 
as contents by a content distribution service, such as an 
electronic music distribution service. 

2. Description of Background Art 

[0003] Electronic music distribution enables users 
to purchase and receive music contents (e.g., songs 
and albums) via the Internet. Such technology has the 
potential to greatly change the market for recorded 
music and is gradually becoming possible as the neces- 
sary infrastructure is introduced. One way to store 
music contents that are obtained from an electronic 
music distribution service is on semiconductor memory 
cards whose portability makes them ideal. Accordingly, 
a great increase is expected in the demand for such 
cards. 

[0004] Music contents are not restricted to merely 
containing audio data. As one example, "mixed-media" 
audio contents can include related images that are to be 
displayed when music is played back. Such mixed- 
media audio contents can be used for "karaoke soft- 
ware" that is composed of a backing audio track and 
images for the lyrics of a song and a background. It is 
believed such mixed-media audio contents will also be 
subject to electronic music distribution, so that it is nec- 
essary to consider how such contents should be stored 
in a semiconductor memory card. 
[0005] The following describes how mixed-media 
music contents are stored on a recording medium, such 
as a CD (Compact Disc), which is to say, how audio 
data and image data are conventionally stored on a 
recording medium. 

[0006] To enable a player to play back music and 
display images, a conventional mixed-media music con- 
tent is recorded onto a recording medium as multiplexed 
data produced by multiplexing audio data for the music 
with image data for the lyrics and/or background 
images. When the multiplexed data is reproduced, the 
image data can be displayed while the audio data is 



being played back. 

[0007] A CD-Graphics disc is one example of a 
medium that enables image data to be displayed while 
audio data is being played backed by having such data 
multiplexed together. When producing a CD-Graphics 
disc, data is multiplexed in units composed of 16-bit 
main codes and subcodes. Audio data is assigned to 
the 16-bit main codes, while image data for lyrics, back- 
ground images and the like is assigned to the subcodes. 
When playback commences for any of the music con- 
tents recorded on a CD-Graphics disc, the audio data 
assigned to the 16-bit main codes is successively 
played back while the image data assigned to the sub- 
codes is successively displayed. 
[0008] When audio data and image data are multi- 
plexed together in this way, it becomes necessary to 
provide separate images to each music content in a 
music album. This means that in this conventional mul- 
tiplexing method, a disc producer has had to go to the 
trouble of producing at least one image for each music 
content. 

[0009] It is believed that fans of major recording art- 
ists will appreciate having a different image for each 
song (music content) on an album. Since such artists 
can expect to sell many copies of their albums, the cost 
of providing such extra material should be covered by 
sales. 

[0010] However, minor artists cannot expect high 
sales for their work even if different images are provided 
for each song, so that the cost of providing such mate- 
rial may not be offset by sales. 
[001 1] In this way, the commercial effect that results 
from the money and effort expended in the production of 
images will greatly differ depending on whether the art- 
ist is popular. With conventional discs, however, it is 
necessary to assign at least one image to each music 
content, regardless of how popular the recording artist 
is or of how many sales can be expected. As a result, 
producers are dissatisfied with conventional media. 

SUMMARY OF THE INVENTION 

[0012] It is an object of the present invention to pro- 
vide a semiconductor memory card that can reduce the 
effort required when providing images for a plurality of 
audio contents that compose an album. 
[0013] When images are displayed during the play- 
back of audio contents, images that represent the lyrics 
of a song should only be displayed during the playback 
of the corresponding song. Background images, how- 
ever, may be commonly used during the playback of any 
number of songs. As one example, when the songwriter 
or artist is the same, the same picture of the songwriter 
or artist can be used as a background image for a 
number of songs. It is believed that this will make it easy 
for disc producers to store music data (audio objects) 
and image data (picture objects) together. 
[0014] The sharing of image data (still image 
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objects) between a plurality of audio objects can be 
preferably achieved by a semiconductor memory card 
storing: an audio sequence including a plurality of audio 
objects; a plurality of stili image objects; at least one 
piece of playback route information showing an order in 5 
which audio objects, out of the plurality of audio objects 
in the audio sequence, are to be played back; at least 
one piece of first pointer information, each of which cor- 
responds to a piece of playback route information and 
specifies at least one still image object that should be 10 
displayed when the audio objects in the order indicated 
by the corresponding piece of playback route informa- 
tion are played back; and at least one piece of second 
pointer information, each of which corresponds to an 
audio object in the audio sequence and specifies at 15 
least one still image object that should be displayed only 
during playback of the corresponding audio object. 
[0015] A plurality of audio objects in an audio 
sequence are played back in accordance with a play- 
back order given in a piece of playback route informa- 20 
tion. Still image objects that are to be displayed as 
background images during the playback of the audio 
objects are indicated by the first pointer information cor- 
responding to the playback route information. As a 
result, shared still image objects can be displayed dur- 25 
ing the playback period of the plurality of audio objects 
included in the audio sequence, 
[0016] Since the sane images can be used for a 
plurality of tracks, the same image or images can be dis- 
played during the playback of a plurality of audio objects 30 
in an audio sequence that corresponds to an album by 
a minor recording artist. This reduces the cost and effort 
of producing images for such an album. 
[0017] Conversely, a plurality of different images 
can be provided for display during the playback of each 35 
audio object in an audio sequence that corresponds to 
an album by a major recording artist. Displaying a 
number of different images for each track makes the 
album more appealing to customers, and so can 
improve sales. 40 
[0018] When there are still image objects, such as 
for song lyrics, that are to be displayed separately to the 
background images only during the playback of a partic- 
ular track, such still image objects can be specified 
using second pointer information to assign the still 45 
image objects to only the particular track. 
[0019] Here, the semiconductor memory card may 
further store a plurality of symbolic counters, each of 
which corresponds to a still image object and shows 
whether the still image object is specified by any of the so 
at least one piece of first pointer information and the at 
least one piece of second pointer information and, if so, 
how many pieces of first pointer information and second 
pointer information specify the still image object. 
[0020] When deleting audio objects and audio 55 
sequences, the recording apparatus for a semiconduc- 
tor memory card specifies the second pointer informa- 
tion for the deleted audio objects and audio sequences 
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and the first pointer information for any deleted audio 
sequence. The recording apparatus then decrements 
the numbers assigned to still image objects to show 
how many pieces of first pointer information and second 
pointer information specify each object. When the 
number assigned to any still image object reaches zero, 
the recording apparatus assumes that no piece of first 
pointer information or second pointer information speci- 
fies the still image object and so deletes the still image 
object. By deleting unused still image objects in this 
way, the storage capacity of a semiconductor memory 
card can be used more efficiently. 

Brief Description Of The Drawings 

[0021] These and other objects, advantages and 
features of the invention will become apparent from the 
following description thereof taken in conjunction with 
the accompanying drawings which illustrate a specific 
embodiment of the invention. In the Drawings: 

FIG. 1 shows the appearance of a flash memory 
card 31 when viewed from above; 
FIG. 2 shows the construction of the flash memory 
card 31 when viewed from below; 
FIG. 3 shows the hierarchical composition of the 
flash memory card 31 in the embodiments; 
FIG. 4A shows the special region, the authentica- 
tion region and the user region provided in the 
physical layer of the flash memory card 31 ; 
FIG. 4B shows the composition of the authentica- 
tion region and the user region in the file system 
layer; 

FIG. 5 shows the detailed composition of the file 
system layer; 

FIG. 6 is a representation of when the AOB file 
"AOB001.SA1" is divided into five parts that are 
stored in clusters 003, 004, 005, 00A, and 00C; 
FIG. 7 shows one example of the settings of the 
directory entries and file allocation table when the 
AOB file "AOB001.SA1" is recorded in a plurality of 
clusters; 

FIGs. 8A and 8B show what directories are pro- 
vided in the user region and the authentication 
region in the file system layer when the above two 
types of data are recorded in the application layer, 
as well as what kind of files are recorded in which 
directories; 

FIG. 9 shows the correspondence between the file 
"AOBSA1 .KEY" and the AOB files in the SD_Audio 
directories; 

FIG. 10 shows the hierarchical composition of the 
data in an AOB file; 

FIG. 11A shows the parameters stipulated by 
ISO/IEC 13818-7 standard in tabular form; 
FIG. 11B shows the parameters that should be 
used when encoding a file in MPEG-Layer 3 (MP3) 
format in tabular form; 
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FIG. 11C shows the parameters that should be 
used when encoding a file In Windows Media Audio 
(WMA) format in tabular form; 
FIG. 12 shows the detailed construction of an 
AOB_FRAME; 5 
FIG. 13 shows how the byte length of the audio data 
in each of three AOB_F FRAMES is set; 
FIG. 14 shows the correspondence between the 
sampling_frequency and the number of 
AOB.FRAMEs included in an AOB_ELEMENT; w 
FIG. 15 shows examples of the playback periods of 
AOB_ELEMENTs and the playback periods of 
AOB.FRAMEs; 

FIG. 16 shows what is reproduced when the AOBs 
and AOB_BLOCKs recorded in an AOB file are 15 
consecutively played back; 
FIG. 17 shows the hierarchical composition of the 
PlaylistManager and TrackManager used in the 
embodiments in detail; 

FIG. 18 shows the sizes of the PlaylistManager and 20 
the TrackManager; 

FIG. 19 shows the correspondence between the 
TKIs shown in FIG. 1 7 and the AOBs and AOB files 
shown in FIG. 16; 

FIG. 20 shows the detailed data composition of the 25 

TKTMSRT shown in FIG. 17; 

FIG. 21 shows one example of the TKTMSRT; 

FIG. 22 shows the detailed composition of the 

TKGI; 

FIGs. 23A and 23B show the composition of the 30 
BIT; 

FIG. 23C shows the TimeJ_ength field; 
FIG. 24 shows cluster 007 to 00E into which the 
AOB composed of AOB_ELEMENT#1 to 
AOB_ELEMENT#4 are stored; 35 
FIG. 25 shows how the next AOB_FRAME#x+1 to 
be played back is set when forward search is per- 
formed starting from the AOB_FRAME#x in an arbi- 
trary AOB_ E L E M E NT#y in an AOB; 
FIGs. 26A and 26B shows how an AOB, an 40 
AOB_ELEMENT, and an AOB.FRAME that corre- 
spond to an arbitrary playback time code are spec- 
ified; 

FIGS. 27A and 27B show the deletion of a track; 
FIG. 28A shows the TrackManager after the dele- 45 
tion of a track has been performed several times; 
FIG. 28B shows how a new TKI and AOB file are 
written when "Unused" TKIs are present in the 
TrackManager; 

FIGS. 29A and 29B show the TKIs are set when so 

two tracks are combined to produce a new track; 

FIG. 30A shows a Typel AOB; 

FIG. 30B shows Type2 AOBs; 

FIG. 31A shows the combining of a plurality of 

tracks into a single track for a combination of a 55 

Typel + Type2+ Type2+ Typel AOB; 

FIG. 31 B shows the combining of a plurality of 

tracks into a single track for a combination of a 



Typel + Type2+ Type2+ Type2+ Typel AOB; 

FIG. 32A shows a pattern where a Typel AOB is 

present at the end of a preceding track and a Typel 

AOB is present at the start of a next track; 

FIG. 32B shows a pattern where a Typel AOB is 

present at the end of a first track and a Type2 AOB 

is present at the start of a next track; 

FIG. 32C shows a pattern where a Typel and 

Type2 AOB are present at the end of a first track 

and a Typel AOB is present at the start of a next 

track; 

FIG. 32D shows a pattern where a Typel and 
Type2 AOB are present at the end of a first track 
and a Type2 and a Typel AOB is present at the 
start of a next track; 

FIG. 32E shows a pattern where two Type2 AOBs 
are present at the end of a first track and a Typel is 
present at the start of a next track; 
FIGS. 33A and 33B show the division of a track to 
produce two tracks; 

FIGS. 34A and 34B show the content of the 
SD_Audio directory entries in the SD_Audio direc- 
tory including the AOB file "AOB003.SA1 M before 
and after the division of the track; 
FIG. 35A shows the division of an AOB midway 
through AOB_ELEMENT#2; 
FIG. 35B shows the two AOBs, AOB#1 and AOB#2, 
obtained by dividing an AOB midway through 
AOB_ELEMENT#2; 

FIG. 36 shows how the BIT is set when an AOB is 

divided as shown in FIG. 35; 

FIG. 37 shows a specific example of changes in the 

BIT before and after division; 

FIG. 38 shows a specific example of changes in the 

TKTMSRT before and after division; 

FIG. 39A shows the format of a DPL_TK_SRP; 

FIG. 39B shows the format of a PL_TK_SRP; 

FIG. 40 shows the interrelation between the 

Default_PlaylisHnformation, the TKIs, and the 

AOB files; 

FIG. 41 shows example settings for the 

Default_Playlist and several PLIs; 

FIG. 42 shows how the DPL_TK_SRPs correspond 

to TKIs using the same notation as FIG. 40; 

FIGS. 43A and 43B show how the order of tracks is 

rearranged; 

FIGS. 44A and 44B show how the Default_Playlist, 
TrackManager, and AOB files will be updated when 
DPL_TK_SRP#2 and TKI#2 are deleted from the 
DefaulLPIaylist shown in FIG. 40; 
FIGS. 45A and 45B show how a new TKI and 
DPL_TK_SRP are written when an "Unused" TKI 
and DPL_TK_SRP are present; FIGS. 46A and 46B 
show how tracks are combined; 
FIGS. 47A and 47B shows how a track is divided; 
FIG. 48 shows the appearance of a portable play- 
back apparatus for the flash memory card 31 of the 
present embodiments; 
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FIG. 49 shows one example of the display on the 

LCD panel when a playlist Is selected; 

FIGS. 50A to 50E show examples of the display on 

the LCD panel when a track is selected; 

FIGS. 51A to 51C show example operations of the 5 

jog dial; 

FIG. 52 shows the internal construction of the 
reproduction apparatus; 

FIG. 53 shows how data is transferred in and out of 
the double buffer 15; 10 
FIG. 54A and 54B shows how areas in the double 
buffer 15 are cyclically allocated using ring pointers; 
FIG. 55 is a flowchart showing the AOB file read 
procedure; 

FIG. 56 is a flowchart showing the AOB file output 15 
procedure; 

FIG. 57 is a flowchart showing the AOB file output 
procedure; 

FIG. 58 is a flowchart showing the AOB file output 
procedure; 20 
FIGS. 59A to 59D show how the playback time 
code displayed in the playback time code frame on 
the LCD panel 5 is updated in accordance with the 
updating of the variable Playjime; 
FIG. 60 is a flowchart shows the processing of the 25 
CPU 10 when the forward search function is used; 
FIGS. 61 A to 61 D show how the playback time 
code is incremented when the forward search func- 
tion is used; 

FIGS. 62A and 62B show specific examples of how 30 
the time search function is used; 
FIG. 63 is a flowchart showing the processing in the 
editing control program; 

FIG. 64 is a flowchart showing the processing in the 
editing control program; 35 
FIG. 65 is a flowchart showing the processing in the 
editing control program; 

FIG. 66 shows one example of a recording appara- 
tus for recording data onto the flash memory card 
31; 40 
FIG. 67 shows the hardware configuration of the 
recording apparatus; 

FIG. 68 is a flowchart showing the processing dur- 
ing recording; 

FIG. 69 shows the internal construction of a flash 45 
memory card according to the second embodiment 
of the present invention; 

FIGS. 70A and 70B show the internal composition 
of the user data area and the protected area in the 
file system layer; 50 
FIG. 71 A shows the internal composition of a 
"POBXXX.JPG" file; 

FIG. 71 B shows the internal composition of a POB 

file that includes encrypted still image data; 

FIG. 71C shows an example of a POB file that 55 

stores a file path in place of an encrypted data 

body; 

FIG. 72 shows the detailed compositions of the 



PlaylistManager and TrackManager in the second 
embodiment; 

FIG. 73 shows how the POB files shown in FIG. 70 
are specified by TKI_POB_SRPs, PLI_POB_SRPs, 
and DPLI_POB_SRPs; 

FIG. 74 shows the data compositions of the 
TKI_POB_ATR and a TKI_POB_SRP; 
FIG. 75 shows example settings of the 
TKLPOB_SRPs for TKI#1 to TKI#3 in the Track- 
Manager; 

FIG. 76 shows example settings of the 
TKI_POB_SRPs for TKI#4 to TKI#8 in the Track- 
Manager; 

FIG. 77 shows the DPLI_POB_SRPs and 
DPLI_POB_ATR included in the DPLGI; 
FIG. 78 shows an example setting of twenty 
DPLI_POB_SRPs included in the 
DefaulLPIaylistJnformation; 
FIG. 79 is a timing chart showing how a combined 
image is formed when a POB specified by a 
DPLLPOB_SRP included in the 
DefaulLPIaylistJnformation is used as a back- 
ground image and a POB specified by a 
TKLPOB_SRP included in the TrackManager is 
used as a foreground image; 
FIG. 80 shows how a background image and fore- 
ground image are combined at a point six minutes 
after the start of playback according to the 
Default_Playlist_ Information; 
FIG. 81 shows how a background image and fore- 
ground image are Combined at a point sixteen min- 
utes after the start of playback according to the 
DefaulLPIaylistJnformation; 
FIG. 82 shows the PLI_POB_SRPs and 
PLI_POB_ATR included in a PLGI; 
FIG. 83 shows an example setting of twenty 
PLI_POB_SRPs included in a PLI; 
FIG. 84 is a timing chart showing how a combined 
image is formed when a POB specified by a 
PLI_POB_SRP included in a PLI is used as a back- 
ground image and a POB specified by a 
TKI_POB_SRP included in the TrackManager is 
used as a foreground image; 
FIG. 85 shows how a background image and fore- 
ground image are combined.at a point six minutes 
after the start of playback according to a PLI; 
FIG. 86 shows how a background image and fore- 
ground image are combined at a point sixteen min- 
utes after the start of playback according to a PLI; 
FIG. 87 shows an example where the number of 
POB files is reduced by having a number of 
DPLLPOB_SRPs in the 

DefaulLPIaylistJnformation specify the same POB 
files; 

FIG. 88 is a timing chart showing how a combined 
image is formed when a POB specified by a 
DPLI_POB_SRP included in the 
DefaulLPIaylistJnformation is used as a back- 
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ground image and a POB specified by a 

TKI_POB_SRP included in the TrackManager is 

used as a foreground image; 

FIG. 89 shows the internal composition of the 

POBMG; 

FIG. 90 shows how the playback apparatus of the 
second embodiment is used; 
FIG. 91 shows the external appearance of only the 
playback apparatus of the second embodiment; 
FIG. 92 shows the internal construction of the play- 
back apparatus of the second embodiment; 
FIG. 93A shows how the still images stored in the 
plurality of VRAMs 61 can be laid on top of one 
another; 

FIG. 93B also shows how the still images stored in 
the plurality of VRAMs 61 can be laid on top of one 
another; 

FIG. 94 is a flowchart showing the foreground 
image display procedure; 

FIG. 95 is a flowchart showing the background 
image display procedure; 

FIG. 96 is a flowchart showing the background 
image display procedure; 

FIGS. 97A to 97C show what kind of combined 
image is displayed on the LCD panel 5 due to the 
processing in the flowcharts in FIGS. 94 and 95 that 
has a POB specified by a TKI_POB_SRP displayed 
as a foreground image and a POB specified by a 
DPLI_POB_SRP displayed as a background 
image; 

FIGS. 98A to 98C show what kind of combined 
image is displayed on the LCD panel 5 due to the 
processing in the flowcharts in FIGS. 94 and 96 that 
has a POB specified by a TKI_POB_SRP displayed 
as a foreground image and a POB specified by a 
PLI_POB_SRP displayed as a background image; 
FIG. 99 is a flowchart showing the procedure used 
by the recording apparatus of the second embodi- 
ment; 

FIG. 100A shows an example of the phrase timing 
table; and 

FIG. 100B shows an example of the highlight coor- 
dinate table. 

DESCRIPTION OF THE PREFERRED EMBODI- 
MENTS 

[0022] The following describes a semiconductor 
memory card (flash memory card) that is an embodi- 
ment of the present invention, with reference to the 
attached figures. 

[0023] The following paragraphs are arranged into 
a hierarchy using reference numbers with the notation 
given below. 

{x1-x2_x3-x4} 

[0024] The length of a reference number shows the 
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level of the topic in the hierarchy. As a specific example, 
the number x1 is the number of drawing that is being 
referred to in the explanation. The drawings attached to 
this specification have been numbered in the order in 

5 which they are referred to in the specification, so that 
the order of the drawings roughly matches the order of 
the explanation. The explanation of certain drawings 
has been divided into sections, with the reference 
number x2 giving the section number of a section in the 

10 explanation of a drawing indicated by the reference 
number x1. The reference number x3 shows the 
number of an additional drawing that is provided to 
show the details of the section indicated by the section 
number x2. Finally, the reference number x4 shows the 

15 number of a section in the explanation of this additional 
drawing. 

FIRST EMBODIMENT 

20 {1-1_2} External Appearance of the Flash Memory 
Card 31 

[0025] The present explanation starts with the 
external appearance of the flash memory card 31 . FIG. 

25 1 shows the appearance of the flash memory card 31 
when viewed from above, while FIG. 2 shows the con- 
struction of the flash memory card 31 when viewed from 
below. As shown in FIGS. 1 and 2, the flash memory 
card 31 is around the same size as a postage stamp, 

30 and so is large enough to be held by hand. Its approxi- 
mate dimensions are 32.0mm long, 24.0mm wide, and 
2.0mm thick. 

[0026] The flash memory card 31 can be seen to 
have nine connectors on its bottom edge for connecting 
35 the card to a compatible device and a protect switch 32 
on one side to enable the user to set whether overwrit- 
ing of the stored content of the flash memory card 31 is 
permitted or prohibited. 

40 {3-1} Physical Construction of the Flash Memory 
Card 31 

[0027] FIG. 3 shows the hierarchical structure of the 
semiconductor memory card (hereafter referred to as 

45 the "flash memory card 31 ") of the present embodiment. 
As shown in FIG. 3, the flash memory card 31 is con- 
structed with a physical layer, a file system layer and an 
application layer in the same way as a DVD (Digital 
Video Disc), though the logical and physical construc- 

50 tions of these layers are very different to those on a 
DVD. 

{3-2} Physical Layer of the Flash Memory Card 31 

55 [0028] The following describes the physical layer of 
the flash memory card 31. The flash memory is com- 
posed of a plurality of sectors, each of which stores 512 
bytes of digital data. As one example, a 64MB flash 
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memory card 31 will have a storage capacity of 
67,108,864 (=64*1,024*1,024) bytes, so that this card 
will include 1 31 ,072<=671 08864/51 2) valid sectors. 
Once the number of replacement sectors, which are 
provided for use in case of errors, is subtracted, the 5 
remaining number of valid sectors into which various 
kinds of data can be written is around 128,000. 

{3-2_4A-1} Three Regions in the Physical Layer 

10 

[0029] The three regions shown in FIG. 4A are pro- 
vided in the storage area composed of these valid sec- 
tors. These regions are the "special region", the 
"authentication region" and the "user region", and are 
described in detail below. The user region is character- 15 
ized in that a device to which the flash memory card 31 
is connected can freely read or write various kinds of 
data from or into this region. Areas within the user 
region are managed by a file system. 
[0030] The special region stores a media ID that is 20 
a value uniquely assigned to each flash memory card 
31. Unlike the user region, this region is read-only, so 
that the media ID stored in the special region cannot be 
changed. 

[0031] The authentication region is a writeable 25 
region, like the user region. This region differs from the 
user region in that a device connected to the flash mem- 
ory card 31 can access (i.e., read or write data in) the 
authentication region only if the flash memory card 31 
and the device have first confirmed that each other is an 30 
authentic device. In other words, data can only be read 
from or written into the authentication region if mutual 
authentication has been successfully performed by the 
flash memory card 31 and the device connected to the 
flash memory card 31. 35 

{3-2_4A-2} Uses of the Three Regions in the Physi- 
cal Layer 

[0032] When the device connected to the flash 40 
memory card 31 writes data into the flash memory card 
31, the region used to store this data will depend on 
whether copyright protection is necessary for the data 
being written. When data that requires copyright protec- 
tion is written into the flash memory card 31 , the data is 45 
encrypted using a predetermined encryption key (called 
a "FileKey") before being written into the user area. This 
FileKey can be freely set by the copyright holder and, 
while the use of this FileKey provides some level of cop- 
yright protection, the FileKey used for encrypting the so 
written data is itself encrypted to make the copyright 
protection more secure. Any value obtained by subject- 
ing the media ID stored in the special region into a pre- 
determined calculation can be used to encrypt the 
FileKey. The encrypted FileKey produced in this way is 55 
stored in the authentication region. 
[0033] Since data that requires copyright protection 
is subjected to a two-step encryption process where the 



data is encrypted using a FileKey that is itself encrypted 
based on the media ID, copyright infringement, such as 
the production of unauthorized copies of this data, will 
be extremely difficult. 

{3-2_4B-1} Overview of the File System 

[0034] As can be understood, the construction of 
the physical layer of the flash memory card 31 strength- 
ens the copyright protection of the data written in the 
flash memory card 31. The following describes the file 
system layer present on this physical layer. While the file 
system layer of a DVD uses a UDF (Universal Disk For- 
mat)-type file system, the file system layer of the flash 
memory card 31 uses a FAT (File Allocation Table) -type 
file system, as described in ISO/IEC 9293. 
[0035] FIG. 4B shows the construction of the 
authentication region and the user region in the file sys- 
tem layer. As shown in FIG. 4B, the authentication 
region and the user region in the file system each 
include "partition boot sectors", a "file allocation table 
(FAT)", a "root directory", and a "data region", meaning 
that the authentication region and the user region have 
the same construction, FIG. 5 
shows the various parts of these file systems in more 
detail. The following describes the construction of the 
user region with reference to FIGS. 4A. 4B and 5. 

{3-2_4B-2} Partition Boot Sectors 

[0036] The partition boot sectors are sectors that 
store the data that will be referred to by a standard per- 
sonal computer that is connected to the flash memory 
card 31 when the flash memory card 31 is set as the 
boot disk for the operating system (OS) of the personal 
computer. 

{3-2_4B-3_5} Data Region 

[0037] The data region can be accessed by a 
device connected to the flash memory card 31 in units 
no smaller than a "cluster". While each sector in the 
flash memory card 31 is 512 bytes in size, the cluster 
size is 16KB, so that the file system layer reads and 
writes data in units of 32 sectors. 
[0038] The reason the cluster size is set at 16KB is 
that when data is written onto the flash memory card 31 , 
part of the data stored in the flash memory card 31 first 
has to be erased before the write can be performed. 
[0039] The smallest amount of data that can be 
erased in the flash memory card 31 is 16KB, so that set- 
ting the smallest erasable size as the cluster size means 
that data writes can be favorably performed. The arrow 
ff2 drawn using a broken line in FIG. 5 shows the plural- 
ity of clusters 002,003,004,005 . . . included in the data 
region. The numbers 002,003,004,005,006,007,008 . . . 
used in FIG. S5 are the three-digit hexadecimal cluster 
numbers that are exclusively assigned to identify each 
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cluster. Since the smallest unit by which access can be 
performed is one cluster, storage positions within the 
data region are indicated using cluster numbers. 

{3-2_4B-4_5} File Allocation System 5 

[0040] The file allocation system has a file system 
construction in accordance with ISO/IEC 9293 stand- 
ard, and so is made up of a plurality of FAT values. Each 
FAT value corresponds to a cluster and shows which w 
cluster should be read after the cluster corresponding to 
the FAT value. The arrow ff1 shown by a broken line in 
FIG. 5 shows the plurality of FAT values 
002,003,004,005 . . . that are included in the file alloca- 
tion table. The numbers 002,003,004,005 . . . assigned 15 
to each FAT value show which cluster corresponds to 
each FAT value and therefore are the cluster numbers of 
the clusters corresponding to the FAT values. 

{3-2_4B-5_5-1} Root Directory Entries 20 

[0041] The "root directory entries" are information 
showing what kinds of files are present in the root direc- 
tory. As specific examples, the "filename" of an existing 
file, its "filename extension", the "revision time/date" 25 
and "number of first cluster in file" showing where the 
start of the file is stored can be written as the root direc- 
tory entry of a file. 

{3-2_4B-5_5-2} Directory Entries for Subdirectories 30 

[0042] Information relating to files in the root direc- 
tory is written as root directory entries, though informa- 
tion relating to subdirectories is not written as the root 
directory entries. Directory entries for subdirectories are 35 
instead produced in the data region. In FIG. 5, the SD- 
Audio directory entry given in the data region is one 
example of a directory entry for a subdirectory. Like a 
root directory entry, an SD-Audio directory entry 
includes the "filename" of a file present in this subdirec- 40 
tory, its "filename extension", the "revision time/date" 
and "number of first cluster in file" showing where the 
start of the file is stored. 

{3-2_4B-5_6-1} Storage Format for AOB Files 45 

[0043] The following describes the file storage 
method by showing how a file named "AOB001 .SA1" is 
stored in the SD-Audio directory, with reference to FIG. 
6. Since the smallest unit by which the data region can so 
be accessed is one cluster, the file "AOB001.SA1" 
needs to be stored in the data region in parts that are no 
smaller than one cluster. The file "AOB001.SA1" is 
therefore stored having first been divided into clusters. 
In FIG. 6, the file "AOBG01.SA1" is divided into five 55 
parts in keeping with the cluster size, and the resulting 
parts are stored into the clusters numbered 003, 004, 
005, 00A, and 00C. 



{3-2_4B-5_7-1} Storage Format for AOB Files 

[0044] When the file "AOB001.SA1" is divided up 
into parts and stored, a directory entry and the file allo- 
cation table need to be set as shown in FIG. 7. FIG. 7 
shows one example of how the directory entry and file 
allocation table need to be set when the file 
"AOB001.SA1" is stored having been divided up into 
parts and stored. In FIG. 7, the start of the file 
"AOB001.SA1" is stored in cluster 003, so that cluster 
number 003 is written into "the number of first cluster in 
file" in the SD-Audio directory entry to indicate the clus- 
ter storing the first part of the file. As shown in FIG. 7, 
the following parts of the file "AOB001.SA1" are stored 
in clusters 004 and 005. As a result, while the FAT value 
003(004) corresponds to cluster 003 that stores the first 
part of the file "AOB001 .SA1", this value indicates clus- 
ter 004 as the cluster storing the next part of the file 
"AOB001.SA1". In the same way, while the FAT values 
004(005) and 005(00A) respectively correspond to clus- 
ters 004 and 005 that store the next parts of the file 
"AOB001.SA1", these values respectively indicate clus- 
ter 005 and cluster 0OA as the clusters storing the next 
parts of the file "AOB001.SA1". By reading the clusters 
with the cluster numbers written into these FAT values in 
order as shown by the arrows fk1 , fk2, fk3, fk4, fk5 . . . 
in FIG. 7, all of the parts produced by dividing the file 
"AOB001.SA1" can be read. As explained above, the 
data region of the flash memory card 31 is accessed in 
units of clusters, each of which is associated with a FAT 
value. Note that the FAT value that corresponds to the 
cluster storing the final part of an AOB file (the cluster 
00C in the example shown in FIG. 7) is set the cluster 
number FFF to show that the corresponding cluster 
stores the final part of a file. 

[0045] This completes the explanation of the file 
system in the flash memory card 31 of the present 
invention. The following describes the application layer 
that exists on this file system. 

{3-3} Overview of the Application Layer in the Flash 
Memory Card 31 

[0046] An overview of the application layer in the 
flash memory card 31 is shown in FIG. 3. As shown by 
the arrow PN2 drawn with a broken line in FIG. 3, the 
application layer in the flash memory card 31 is com- 
posed of presentation data and navigation data that is 
used to control the playback of the presentation data. As 
shown by the arrow PN2, the presentation data includes 
sets of audio objects (AOB sets) that are produced by 
encoding audio data that represents music, for exam- 
ple. The navigation data includes a "Playlist Manager" 
(PLMG) and a "TrackManager" (TKMG). 

{3«3_8A,B-1} Directory Composition 

[0047] FIGS. 8A and 8B show what kind of directo- 
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ries are present in the user region and the authentica- 
tion region in the file system layer when these two types 
of data are stored in the application layer, as well as 
showing what files are arranged into these directories. 
[0048] The filenames "SDJUJDIO.PLM" and 
"SD.AUDIO.TKM" in FIG. 8A indicate the files in which 
the PlaylistManager (PLMG) and TrackManager 
(TKMG) composing the navigation information are 
stored. Meanwhile, the filenames "AOB001.SA1", 
, 'AOB002.SA1 ,, 1 "AOB003.SA1 H , "AOB004.SA1", . . . 
indicate the files ("AOB" files) storing the audio objects 
that are the presentation data. The letters "SA" in the 
filename extension of the filename "AOBOxx.SAI" are 
an abbreviation for "Secure Audio", and show that the 
stored content of this file requires copyright protection. 
Note that while only eight AOB files are shown in the 
example in FIG. 8A, a maximum of 999 AOB files can be 
stored in an SD-Audio directory, 
[0049] When copyright protection is required for 
presentation data, a subdirectory called an "SD-Audio 
directory" is provided in the authentication region and 
an encryption key storing file "AOBSA1 .KEY" is pro- 
duced in this SD-Audio directory. 
[0050] FIG. 8B shows the encryption key storing file 
"AOBSA1 .KEY" that is stored under the "SD-Audio" leg- 
end (i.e., within the "SD-Audio directory"). This encryp- 
tion key storing file "AOBSA1.KEY" stores a sequence 
of encryption keys that is produced by arranging a plu- 
rality of encryption keys into a predetermined order. 
[0051] The SD-Audio directory shown in FIGS. 8A 
and 8B is stored In a server computer managed by a 
record label that uses electronic music distribution. 
When a consumer orders a music content, the corre- 
sponding SD-Audio directory is compressed, encrypted 
and transmitted to the consumer via a public network. 
The consumer's computer receives this SD-Audio direc- 
tory, decrypts it, decompresses it and so obtains the 
original SD-Audio directory. Note that the expression 
"public network" here refers to any kind of network that 
can be used by the public, such as a wired communica- 
tion network, e.g., an ISDN network, or a wireless com- 
munication network, e.g., a mobile telephone system. It 
is also possible for a consumer's computer to download 
an AOB file from a server computer operated by a 
record label and then produce an SD-Audio directory, 
such as that shown in FIGS. 8A and 8B, in the flash 
memory card 31. 

{3-3 9-1} Correspondence between the 
"AOBSA1.KEY" file and the AOB files 

[0052] FIG. 9 shows the correspondence between 
the "AOBSA1 .KEY" file in the SD-Audio directory and 
the AOB files. The FileKeys used when encrypting files 
in the user region shown in FIG. 9 are stored in the cor- 
responding encryption key storing file in the authentica- 
tion region. 

[0053] The encrypted AOB files and the encryption 



key storing file correspond according to the predeter- 
mined rules (1), (2), and (3) described below. 

(1) The encryption key storing file is arranged into a 
5 directory with the same directory name as the 

directory in which the encrypted file is stored. In 
FIG. 9, AOB files are arranged into the SD-Audio 
directory in the user region and the' encryption key 
storing file is arranged into a directory called the 
10 SD-Audio directory in the authentication region, in 
accordance with this rule. 

(2) The encryption key storing file is given a 
filename produced by combining the first three let- 
ters of the filename of the AOB files in the data 

15 region with the predetermined ".key" extension. 
When the filename of an AOB file is "AOB001 .SA1", 
the encryption key storing file is given the filename 
"AOBSA1 .KEY" produced by adding the first three 
characters "AOB", "SA1", and the extension ".key", 

20 as shown by the arrows nk1 and nk2 in FIG. 9. 

(3) The filename of an AOB file is given a serial 
number showing the position of the FileKey corre- 
sponding to this audio object in the sequence of 
encryption keys given in the encryption key storing 

25 file. 

[0054] The "File Key Entries #1 , #2, #3 . . . #8" show 
the first positions of the regions in which the respective 
FileKeys in the encryption key storing file are stored. 

30 Meanwhile, the filenames of AOB files are assigned the 
serial numbers "001", "002", "003", "004" .... These 
serial numbers show the positions of the corresponding 
FileKeys in the encryption key sequence, so that the 
FileKey that was used to encrypt each AOB file will be 

35 present in the "FileKey Entry" with the same serial 
number. In FIG. 9, the arrows Ak1, Ak2, Ak3, . . . show 
the correspondence between AOB files and FileKeys. In 
other words, the file "AOB001.SA1" corresponds to the 
FileKey whose storage position is indicated by the "File- 

ao Key Entry#1", thefile "AOB002.SAr corresponds to the 
FileKey whose storage position is indicated by the "File- 
Key Entry#2", and the file "AOB003.SA1" corresponds 
to the FileKey whose storage position is indicated by the 
"FileKey Entry#3". As can be understood from rule (3), 

45 different FileKeys are used to encrypt different AOB 
files, with these FileKeys being stored in "FileKey 
Entries" with the serial numbers "001", "002", "003", 
"004" etc., given in the filenames of the corresponding 
AOB files. 

50 [0055] Since each AOB file is encrypted using a dif- 
ferent FileKey, the exposure of the encryption key used 
for one AOB file will not enable users to decrypt other 
AOB files. This means that when AOB files are stored in 
an encrypted form on a flash memory card 31 , the dam- 

55 age caused by the exposure of one FileKey can be min- 
imized. 
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{3-3_10-1} Internal Composition of an AOB file 

[0056] The following describes the internal compo- 
sition of an AOB file. FIG. 10 shows the hierarchical 
data structure of an AOB file. The first level in FIG. 10 5 
shows the AOB file, while the second level shows the 
audio object (AOB) itself. The third level shows the 
AOB_BLOCKs, the fourth level an AOB_ELEMENT, and 
the fifth level an AOB.FRAME. 

[0057] The AOB_FRAME on the fifth level in FIG. w 
10 is the smallest unit composing the AOB, and is com- 
posed of audio data in ADTS (Audio Data Transport 
Stream) format and an ADTS header. Audio data in 
ADTS format is encrypted according to MPEG2-AAC 
(Low Complexity Profile) format and is stream data that 15 
can be played back at a transfer rate of 16Kbps to 
144Kbps. Note that the transfer rate for PCM (Pulse 
Code Modulation) that is recorded on a conventional 
compact disc is 1.5Mbps, so that data in ADTS format 
generally uses a lower transfer rate than PCM. The data 20 
construction of a sequence of AOB_FRAMEs is the 
same as the sequence of audio frames included in an 
audio data transport stream distributed by an electronic 
music distribution service. This means that the audio 
data transport stream to be stored as AOB_FRAME 25 
sequence is encoded according to MPEG2-ACC stand- 
ard, encrypted, and transmitted on a public network to 
the consumer. AOB files are produced by dividing the 
transmitted audio data transport stream into a 
sequence of AOB_FRAMEs and storing these 30 
AOB.FRAMEs. 

{3-3.1 0-1_11} MPEG2-AAC 

[0058] MPEG2-AAC is described in detail in 35 
ISO/IEC 1381 8-7:1 997(E) "Information Technology - 
Generic Coding of Moving Pictures and Associated 
Audio information - Part7 Advanced Audio Coding 
(AAC)". 

[0059] It should be noted that audio objects can 40 
only be compressed according to MPEG2-AAC using 
the parameters in the parameter table shown in FIG. 
11A that is defined in ISO/IEC1 3818-7. This parameter 
table is composed of "Parameter" column, a "Value" col- 
umn, and a "Comment" column. 45 
[0060] The legend "profile" in the Parameter column 
shows the only LC-profile can be used, as stipulated 
under ISO/IEC 13838-7. The legend 
"sampling_frequency#index" in the Parameter column 
shows that the sampling frequencies "48kHz, 44.1kHz, so 
32kHz, 24kHz, 22.05kH2, and 16kHz" can be used. 
[0061] The legend 
"number_of_data_block_in_frame" in the Parameter 
column shows that the ratio of one header to one 
raw_data_ block is used. 55 
[0062] Note that while this explanation describes 
the case where AOB_FRAMEs are encoded according 
to MPEG- AAC format, AOB_FRAMEs may instead be 
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encoded according to another format, such as MPEG- 
Layer3 (MP3) format or Windows Media Audio(WMA). 
When doing so, the parameters shown in the parameter 
tables of FIG. 11Bor FIG. 11C must be used. 

{3-3_10-2_12} Composition of an AOB.FRAME 

[0063] While each AOB_FRAME includes audio 
data that is encoded according to the restrictions 
described above, the data length of the audio data in 
each AOB_FRAME is restricted to a playback time of 
only 20ms. However, since MPEG2-AAC is a variable 
bitrate (VBR) encoding method, the data length of the 
audio data in each AOB_FRAME will vary. The following 
describes the composition of an AOB_FRAME, with ref- 
erence to FIG. 12. 

[0064] The first level in FIG. 12 shows the overall 
composition, while the second level shows how each 
part of an AOB_FFRAME is encrypted. As can be seen 
from the drawing, the ADTS header corresponds to a 
non-encrypted part. The audio data includes both an 
encrypted part and a non-encrypted part. The 
encrypted part of the audio data is composed of a plu- 
rality of eight-byte pieces of encrypted data, each of 
which is produced by encrypting an eight-byte piece of 
audio data using a 56-bit FileKey. When encryption is 
performed on 64-bit pieces of audio data, the non- 
encrypted part of the audio data is simply a final part of 
the data that cannot be encrypted due to it being shorter 
than 64 bits. 

[0065] The third level in FIG. 12 shows the content 
of the ADTS header that is in the non-encrypted part of 
the AOB_FRAME. The ADTS header is seven bytes 
long, and includes a 12-bit synch word (set at FFF), the 
data length of the audio data in this AOB_FRAME, and 
the sampling frequency used when the audio data was 
encoded. 

{3-3_10-3_13} Setting of the Byte Length of an 
AO B_ FRAME 

[0066] FIG. 13 shows how the byte length of the 
audio data in each of three AOB_FRAMEs is set. In 
FIG. 13, the data length of audio data#1 included in 
AOB_FRAME#1 is x1. the data length of audio data#1 
included in AOB_FRAME#2 is x2, and the data length of 
audio data#1 included in AOB_FRAME#3 is x3. When 
the data lengths x1 , x2, and x3 are all different, the data 
length x1 will be written in the ADTS header of 
AOB_FRAME#1, the data length x2 will be written in the 
ADTS header of AOB_FRAME#2, and the data length 
x3 will be written in the ADTS header of 
AOB_FRAME#3. 

[0067] Although the audio data is encrypted, the 
ADTS header is not, so that a playback device can know 
the data length of the audio data in an AOB_FRAME by 
reading the data length given in the ADTS header of the 
AO B_ FRAME. 
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[0068] This completes the explanation of an 
AOB_FRAME. 

{3-3_10-4} AOB.ELEMENT 

5 

[0069] The following describes the AOB_ELEMENT 
shown on the fourth level in FIG. 10. 
[0070] An "AOB_ELEMENT" is a group of consecu- 
tive AOB_FRAMEs. The number of AOB_FRAMEs in 
an AOB_ELEMENT depends on the value set as the 10 
sampling_frequencyjndex shown in FIG. 11A and the 
encoding method used. The number of AOB_FRAMEs 
in an AOB_ELEMENT is set so that the total playback 
time of the included AOB_FRAMEs will be around two 
seconds, with this number depending on the sampling 15 
frequency and encoding method used. 

{3-3_10-5_14} Number of AOB.FRAMEs in an 
AOB_ELEMENT 

20 

[0071] FIG. 14 shows the correspondence between 

the sampling frequency and the number of 

AOB_FRAMEs included in an AOB_ELEMENT. The 

number N given in FIG. 14 represents the playback 

period of an AOB_ELEMENT in seconds. When MPEG- 25 

ACC is used as the encoding method, the value of N is 
ii2« 

[0072] When the sampling_frequency is 48kHz, the 
number of AOB_FRAMEs included in an 
AOB_ELEMENT is given as 94(=47*2), while when the 30 
sampling_frequency is 44.1kHz, the number of 
AOB_ FRAMES included in an AOB.ELEMENT is given 
as 86(=43*2). When the sampling_frequency is 32kHz, 
the number of AOB_ FRAMES is given as 64(=32*2), 
when the sampling_frequency is 24kHz, the number of 35 
AOB_FRAMEs is given as 48(=24*2), when the 
sampling_frequency is 22.05kHz, the number of 
AOB_FRAMEs is given as 44(=22*2), and when the 
sampling_frequency is 16kHz, the number of 
AOB_FRAMEs included in an AOB_ELEMENT is given AO 
as 32(=16*2). However, when an editing operation, such 
as the division of an AOB, has been performed, the 
number of AOB_FRAMEs included in an 
AOB_ELEMENT at the start or end of an AOB may be 
Jess than a number calculated in this way. 45 
[0073] While no header or other special information 
is provided for each AOB_ELEMENT, the data length of 
each AOB.ELEMENT is instead shown by a time 
search table. 

50 

{3-3_10-6__15} One Example of the Playback Periods 
of AOB_ELEMENTs and AOB.FRAMEs 

[0074] FIG. 15 shows one example of the playback 
periods of AOB.ELEMENTs and AOB_FRAMEs. The 55 . 
first level in FIG. 15 shows a plurality of AOB_BLOCKs, 
while the second level shows a plurality of 
AOB_ELEMENTs. The third level shows a plurality of 



AOB_FRAMEs. 

[0075] As shown in FIG. 15, an AOB_ELEMENT 
has a playback period of around 2.0 seconds, while an 
AOB_FRAME has a playback period of 20 milliseconds. 
The "TMSRT.entry" given to each AOB_ELEMENT 
shows that the data length of each AOB_ELEMENT is 
given in the time search table. By referring to the 
TMSRT_entries, a playback apparatus can perform a 
forward or backward search where, for example, inter- 
mittent bursts of music are played back by repeatedly 
playing back 240 milliseconds of audio data and then 
skipping two seconds of audio data in the desired direc- 
tion. 

{3-3.10-7} AO B_ BLOCK 

[0076] This completes the explanation of an 
AOB_ELEMENT. The following describes the concept 
of the AOB_BLOCKs shown on the third level of the 
data construction of an AOB file given in FIG. 10. 
[0077] Each "AOB.BLOCK" is composed of valid 
AOB_ELEMENTs. Only one AOB_BLOCK exists in 
each AOB_FILE. While an AOB.ELEMENT has a play- 
back period of around two seconds, an AOB_BLOCK 
has a maximum playback period of 8.4 minutes. The 8.4 
minute limitation is imposed to restrict the size of the 
time search table to 504 bytes or less. 

{3-3_10-8} Restriction of the Time Search Table 

[0078] The following describes in detail why the size 
of the time search table is restricted by limiting the play- 
back period. 

[0079] When a playback apparatus performs a for- 
ward or backward search, the playback apparatus skips 
the reading of two seconds of audio data before playing 
back 240 milliseconds. When skipping two seconds of 
data, the playback apparatus could in theory refer to the 
data lengths shown in the ADTS headers of 
AOB_FRAMEs, though this would mean that the play- 
back apparatus would have to consecutively detect 100 
(2 seconds/20 milliseconds) AOB_FRAMEs just to skip 
two seconds of audio data. This would amount to an 
excessive processing load for the playback apparatus. 
[0080] To reduce the processing load of a playback 
apparatus, the read addresses for data at two-second 
intervals can be written into a time search table that is 
then referred to by the playback apparatus when per- 
forming a forward or backward search. By writing infor- 
mation that enables read addresses that are two or four 
seconds ahead or behind to be found quickly into the 
time search table (such information being the data sizes 
of AOB_ELEMENTs), a playback apparatus will only 
need to refer to this information when performing a for- 
ward or backward search. The data size of audio data 
with a playback period of two seconds will depend on 
the bitrate used when playing back the audio data. As 
stated earlier, a bitrate in the range of 16Kbps to 
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144Kbps is used, so that the amount of data played 
back in two seconds will be in a range from 4KB 
(=16Kbps x 2/8) to 36KB(=144Kbps x 2/8). Since the 
amount of data played back in two seconds will be in a 
range from 4KB to 36KB, the data length of each entry 
in the time search table for writing the data length of 
audio data needs to be two bytes (=16 bits) long. This is 
because a 16-bit value is capable of expressing a 
number in the range 0-64KB. 

[0081] On the other hand, if the total data size of the 
time search table needs to be restricted to 504 bytes 
(this being the data size of the TKTMSRT described 
later), for example, the maximum number of entries in 
the time search table can be calculated as 504/2=252. 
[0082] Since an entry is provided every two sec- 
onds, the playback time corresponding to this maximum 
of 252 entries is 504 seconds (=2s*252), or, in other 
words, 8 minutes and 24 seconds (=8.4 minutes). This 
means that setting the maximum playback period for an 
AO B_ BLOCK at 8.4 minutes limits the data size of the 
time search table to 504 bytes. 

{3-3_10-9} Regarding AOBS 

[0083] This concludes the description of 
AOB_BLOCKs. The following describes AOBs. 
[0084] The AOBs shown on the second level of FIG. 
10 are regions that have invalid areas at either end. 
Only one AOB is present in each AOB file. 
[0085] The invalid areas are regions that are read 
and written along with the AOB_BLOCKs and are 
stored in the same clusters as the AOB_BLOCKs. The 
start and end position of the AOB_BLOCKs within an 
AOB are shown by BITs included in the navigation data. 
These BITs are described in detail later in this specifica- 
tion. 

[0086] This completes the explanation of what data 
is stored in an AOB file. The following describes what 
kind of content is played back when the eight AOBs and 
AOB_BLOCKs shown in the AOB file in FIG. 9 are suc- 
cessively read. 

{3-3_10-10_16} 

[0087] FIG. 16 shows the playback content when 
the AOBs and AOB_BLOCKs in this AOB file are suc- 
cessively read. The first level in FIG. 16 shows the eight 
AOB files in the user region, while the second level 
shows the eight AOBs recorded in these AOB files. The 
third level shows the eight AOB_BLOCKs included in 
these AOBs. 

[0088] The fifth level shows the titles of five con- 
tents composed by these AOB files. In this example, the 
"contents" are the five songs SongA, SongB, SongC, 
SongD, and SongE, while the "title" is a music album 
composed of these five songs. The broken tines AS1, 
AS1 , AS3, . . . AS7, and AS 8 show the correspondence 
between the AOB_BLOCKs and the parts into which the 



album is divided, so that the fourth level in FIG. 16 
shows the units used to divide the music album shown 
on the fifth level. 

[0089] By referring to the broken lines, it can be 
5 seen that the AOB_BLOCK included in AOB#1 is a song 
(SongA) with a playback period of 6.1 minutes. The 
AOB_BLOCK included in AOB#2 is a song (SongB) with 
a playback period of 3.3 minutes. The AOB_BLOCK 
included in AOB#3 is a song (SongC) with a playback 
10 period of 5.5 minutes. In this way, "AOB001.SA1" to 
n AOB003.SA1" each correspond to a different song. 
The sixth level of FIG. 1 6 is a track sequence composed 
of tracks TrackA to TrackE. These tracks TrackA-TrackE 
correspond to the five songs SongA, SongB, SongC, 
15 SongD, and SongE, and are each treated as a separate 
playback unit. 

[0090] On the other hand, AOB#4 has a playback 
period of 8,4 minutes and is the first (or "head") part of 
the song SongD that has a playback period of 30.6 min- 

20 utes. The AOB_BLOCKs included in AOB#5 and 
AOB#6 are middle parts of the song SongD and also 
have playback periods of 8.4 minutes. The 
AOB_BLOCK included in AOB#7 is the end part of the 
song SongD and has a playback period of 5,4 minutes. 

25 In this way, a song that has a total playback period of 
30.6 minutes is divided into (8.4 + 8.4 + 8.4 + 5.4- 
minute) parts that are each included in a different AOB. 
As can be seen from FIG. 16, every song included in an 
AOB file is subjected to a maximum playback period of 

30 8.4 minutes. 

[0091] This explanation clearly shows that limiting 
the playback periods of AOBS as described above 
restricts the data size of the time search table corre- 
sponding to each AOB. The following describes the nav- 

35 igation data included in each time search table, 

{3-3_8A,B-2} 

[0092] The navigation data is composed of the two 
AO files "SD_Audio.PLM" and "SD_Audio.TKM" mentioned 
earlier. The file "SD_Audio.PLM" includes the Playlist- 
Manager, while the file "SD_Audio.TKM M includes the 
TrackManager. 

[0093] As mentioned as part of the explanation of 
45 the presentation data, a plurality of AOB files store 
encoded AOBs, though no other information, such as 
the playback period of the AOBs, the names of the 
songs represented by the AOBs, or credits for the song- 
writers), is given. While a plurality of AOBs are 
50 recorded in a plurality of AOB files, no indication as to 
the playback order of the AOBs is provided. To inform a 
playback apparatus of such information, the TrackMan- 
ager and PlaylistManager are provided. 
[0094] The TrackManager shows the correspond- 
55 ence between the AOBs recorded in AOB files and 
tracks, and includes a plurality of pieces of track man- 
agement information that each give a variety of informa- 
tion, such as the playback period of AOBs and the song 
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names and songwriters of the various AOBs. 
[0095] In this specification, the term "track" refers to 
a meaningful playback unit for users, so that when cop- 
yrighted music is stored on a flash memory card 31, 
each song is a separate track. Conversely, when an 
"audio book" (i.e., copyrighted literature stored as 
recorded audio) is recorded on a flash memory card 31 , 
each chapter or paragraph can be set as a separate 
track. The TrackManager is provided to manage a plu- 
rality of AOBs recorded in a plurality of AOB files as a 
group of tracks. 

[0096] A Playlist sets the playback order of a plural- 
ity of tracks. A plurality of Playlists can be included in the 
PlaylistManager. 

[0097] The following describes the TrackManager 
with reference to the drawings. 

{17-1_18} Detailed Composition of the PlaylistMan- 
ager and TrackManager 

[0098] FIG. 17 shows the detailed composition of 
the PlaylistManager and TrackManager in this embodi- 
ment as a hierarchy. FIG. 18 shows the sizes of the 
PlaylistManager and the TrackManager. The right side 
of FIG. 17 shows the items on the left side in more 
detail, with the broken lines indicating which items are 
being shown in more detail. 

[0099] As shown in FIG. 17, the TrackManager is 
composed of the Track Information (TKI) #1 , #2, #3, #4 
. , . #n, as shown by the broken line hi. These TKIs are 
information for managing the AOBs recorded in AOB 
files as tracks, and each correspond to a different AOB 
file. From FIG. 17, it can be seen that each TKI is com- 
posed of Track_General_lnformation (TKGI), 
Track_TexL Information (TKTXTI_DA) in which text 
information exclusive to a track can be written, and a 
Track_Time_Search_Table (TKTMSRT) that serves as 
a time search table. 

[0100] From FIG. 18, it can be seen that each TKI 
has a fixed size of 1,024 bytes, which means that total 
size of the TKGI and the TKTXTI.DA is fixed at 512 
bytes due to the size of the TKTMSRT being fixed at 
512 bytes. In the TrackManager, a total of 999 TKIs can 
be set. 

[0101] As shown by the broken line h3, the 
TKTMSRT is composed of a TMSRT_Header and 
TMSRT.entries #1 , #2, #3 . . . #n. 

{17-2_19> Correspondence Of TKI with AOB files 
and AOBs 

[0102] FIG. 19 shows how the TKIs shown in FIG. 
17 correspond to the AOB files and AOBs shown in FIG. 
16. The boxes on the first level in FIG. 19 show a 
sequence of tracks composed of tracks TrackA to 
TrackE, the large frame on the second level shows the 
TrackManager, while the third and fourth levels show the 
eight AOB files given in FIG. 1 6. The eight AOB files are 



recorded in the eight AOBs shown in FIG. 16, and com- 
pose a music album including tracks TrackA, TrackB, 
TrackC, TrackD, and TrackE. The second level shows 
the eight TKIs. The numbers "1", "2", "3", "4" assigned 
5 to each TKI are the serial numbers used to identify each 
TKI, with each TKI corresponding to the AOB file that 
has been given the same serial number 
001,002,003,004,005 .... 

[0103] With this in mind, it can be seen from FIG. 19 
w that TKI#1 corresponds to the file "AOB001.SA1", that 
TKI#2 corresponds to the file "AOB002.SAr, TKI#3 
corresponds to the file "AOB003.SA1", and TKI#4 cor- 
responds to the file "AOB004.SA1". The correspond- 
ence between TKIs and AOB_FRAMEs is shown by the 
15 arrows TA1, TA2, TA3, TA4 . . , in FIG. 19. 

[0104] In this way, each TKI corresponds to a differ- 
ent AOB recorded in an AOB file and gives detailed 
information that applies only to the corresponding AOB. 

20 {17-3_20} Data Composition of a TKTMSRT 

[0105] The following describes the information that 
applies to single AOBs recorded in AOB files, starting 
with the TKTMSRT. FIG. 20 shows the data composition 

25 of the TKTMSRT in detail. 

[0106] The right side of FIG. 20 shows the detailed 
data composition of the time search table header 
(TMSRT_Header). In FIG. 20, the TMSRTJHeader has 
a data size of eight bytes, and is made up of three fields. 

30 The first two bytes are a TMSRTJD, the next two bytes 
are reserved, and the final four bytes are a Total 
TMSRT_entry_Number. 

[0107] A unique ID for identifying the TMSRT is 
recorded in the "TMSRTJD". The total number of 
35 TMSRT_entries in the present TMSRT is recorded in 
the "Total TMSRT.entry Number". . 

{17-3_21-1) Specific Example of the TKTMSRT 

40 [0108] The following describes a TKTMSRT in 
detail. FIG. 21 shows one example of a TKTMSRT. The 
left side of FIG. 21 shows an AOB, while the right side 
shows the corresponding TKTMSRT. The AOB on the 
left side of FIG. 21 is composed of a plurality of 

45 AOB_ELEMENTs numbered #1, #2, #3 . . . #n that 
occupy the regions numbered AR1 , AR2, AR3 . . . ARn 
to the right. 

[0109] The numbers such as "0", "32000", ,, 64200" l 
"97000", "1203400", and "1240000" show the relative 

so addresses of areas AR1 , AR2, AR3, ARn-1 , ARn occu- 
pied by the AOB_ELEMENTs with respect to the start of 
the AOB_BLOCK. As examples, AOB_ELEMENT#2 is 
recorded at a position that is at a distance "32000" from 
the start of the AOB.BLOCK, while AOB_ELEMENT#3 

55 is recorded at a position that is at a distance "64200" 
from the start of the AO B_ BLOCK and 
AOB_ELEMENT#n-1 is recorded at a position that is at 
a distance "1203400" from the start of the 
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AOB^BLOCK. 

[0110] It should be noted that the distance between 
each occupied region and the start of the AOB_BLOCK 
is not a multiple of a certain value, meaning that the 
regions occupied by AOB_ELEMENTs are not of the 
same size. The reason the occupied regions have differ- 
ent sizes is that the varying amounts of data are used to 
encode each AOB_FRAME. 

[0111] Since the size of the region occupied by 
each AOB_ELEMENT differs, it is necessary to inform a 
playback apparatus in advance of the position of each 
AOB_ ELEMENT in an AOB when performing a jump to 
the start of an AOB_ELEMENT. For this purpose, a plu- 
rality of TMSRT_entries are given in the TKTMSRT. The 
arrows RT1, RT2, RT3 . . . RTn-1 , RTn show the corre- 
spondence between the regions AR1, AR2, AR3 . . . 
ARn-1, ARn occupied by each AOB_ELEMENT and 
TMSRT_entry#1,TMSRT_entry#2,TMSRT_entry#3 . . . 
TMSRT_entry#n-1, TMSRT_entry#n. In other words, 
the size of the region AR1 occupied by 
AOB_ELEMENT#1 is written in the TMSRT_entry#1, 
while the sizes of the regions AR2 and AR3 Occupied 
by AOB_ELEMENT#2 and AOB_ELEMENT#3 are writ- 
ten in the TMSRT_entries #2 and #3. 
[0112] Since the occupied area AR1 takes up the 
region from the start of the AOB to the start of the 
AOB_ELEMENT#2 "32000", the size "32000" (=32000- 
0) is written in the TMSRT_entry#1 . The occupied area 
AR2 takes up the region from the start of the 
AOB_ELEMENT#2 "32000" to the start of the 
AOB_ELEMENT#3 "64200", so that the size "32200" 
(=64200-32000) is written in the TMSRT_entry#2. The 
occupied area AR3 takes up the region from the start of 
the AOB_ELEMENT#3 "64200" to the start of the 
AOB_ELEMENT#4 "97000", so that the size "32800" 
(=97000-64200) is written in the TMSRT_entry#3. In the 
same way, the occupied area ARn-1 takes up the region 
from the start of the AOB_ELEMENT#n-1 "1203400" to 
the start of the AOB_ELEMENT#n "1240000", the size 
"36600" (=1240000-1203400) is written in the 
TMSRT_entry#n-1. 

{17-3.21-2} How the TKTMSRT is read 

[0113] In this way, the data sizes of 
AOB_ELEMENTs are written in a time search table. 
However, since the data length of each AOB_BLOCK is 
restricted to a maximum of 8.4 minutes, the total 
number of AOB_ELEMENTs included in a single AOB is 
limited to a predetermined number ("252" as shown in 
FIG. 20) or less. Since the number of AOB_ELEMENTs 
is restricted, the number of TMSRT_entries correspond- 
ing to AOB_ELEMENTs is also restricted, which 
restricts the size of the TKTMSRT including these 
TMSRT_entries to within a predetermined size. Since 
the size of the TKTMSRT is restricted, a playback appa- 
ratus can read and use TKIs in the following way. 
[0114] The playback apparatus reads a certain 



AOB and on commencing playback of the AOB, reads 
the corresponding TKI and stores it in a memory. This 
corresponding TKI is kept in the memory while the play- 
back of this AOB continues. Once the playback of the 
5 AOB ends, the following AOB is read, and when the 
playback of this AOB commences, the playback appara- 
tus overwrites the TKI corresponding to this following 
AOB into the memory in place of the old TKI. This next 
TKI is kept in the memory while the playback of this fol- 
io lowing AOB continues. 

[0115] By reading and storing TKIs in this way, the 
necessary capacity of the memory in the playback 
apparatus can be minimized while still enabling special 
playback functions such as forward and backward 
15 search to be realized. While the present embodiment 
describes the case where the data length from the first 
address of an AOB_ELEMENT to the first address of 
the next AOB_ELEMENT is written in the 
TMSRT_entry, relative addresses from the start of the 
20 AOB_ BLOCK to the first addresses of 
AOB_ELEMENTs may be written in there instead. 

{17-3.21-3} Specifying a Cluster Including an 
AOB.ELEMENT 

25 

[0116] The following describes how an 
AOB.ELEMENT may be read using the TKTMSRT. The 
TKTMSRT includes the size of each AOB_ELEMENT, 
so that when AO B_E LE M E NT#y, which is the V th 
30 AOB_ELEMENT from the start of an AOB, is to be read, 
the cluster u that satisfies Equation 1 given below is cal- 
culated, and data positioned with the offset v from the 
start of the cluster u is read. 

35 Equation 1 

[0117] 

Cluster u = (Total of the TMSRT_entries from 
40 AOB_ELEMENT#1 to AOB_ELEMENT#y-1 + 
DATA_Offset) / Cluster size 

Offset v = (Total of the TMSRT_entries from 
AOB_ELEMENT#1 to AOB_ELEMENT#y-1 + 
45 DATA.Offset) mod Cluster size 

where c=a mod b indicates that c is the 
remainder produced when a is divided by b 

[01 1 8] The DATA_Offset is written in the BIT and is 
50 described later in this specification. 

{17-4} TKTXLDA 

[0119] This completes the explanation of the time 
55 search table (TKTMSRT). The following describes the 
Track_TextJnformation Data Area(TKTXI_DA) 
recorded in the upper part of the TKTMSRT. 
[0120] The Track_Text_lnformation Data Area 
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(TKTXTLDA) is used to store text information showing 
the artist name, album name, mixer, producer, and other 
such information. This area is provided even when such 
text information does not exist. 

5 

{17-5} TKGI 

[0121] The following describes the TKGI recorded 
in the upper part of the TKTXI_DA. In FIG. 17, several 
sets of information shown as the identifier TKIJD" of 10 
the TKI, the TKI number TKIN", the TKI size TKLSZ", 
a link pointer to the next TKI "TKLLNK.PTR", block 
attributes "TKLBLK_ATR", a playback period 
"TKI_PB_TM M , the audio attributes "TKI_AOB_ATR M , an 
"ISRC", and block information "BIT". Note that only 15 
some of this information has been shown in FIG. 17 to 
simplify the representation. 

{17-5_22-1}TKGI 

20 

[0122] The following describes the composition of a 
TKGI in detail, with reference to FIG. 22. The difference 
between FiG. 17 and FIG. 22 is that the data composi- 
tion of the TKGI that was shown in FIG. 17 is arranged 
on the left side of this drawing, and that the bit composi- 25 
tions of "TKI_BLK_ATR M , "TKI_AOB_ATR" and M ISRC" 
are clearly shown. 

{17-5_22-2} TKIJD 

30 

[0123] A unique ID for a TKI is written in the 
"TKIJD". In the present embodiment, a two-byte "A4" 
code is used. 

{17-5.22-3} TKIN 35 

[0124] A TKI number in the range of 1 to 999 is writ- 
ten in the "TKIN". Note that the TKIN of each TKI is 
unique. In the present embodiment, the position of each 
TKI in the TrackManager is used as the TKIN. This 40 
means that "1" is written as the TKI number of TKI#1, 
"2" is written as the TKI number of TKI#2, and "3" is writ- 
ten as the TKI number of TKI#3. 

{17-5_22-4} TKI_S2 45 

[0125] The data size of the TKI in byte units is writ- 
ten in the "TKLSZ". In FIG. 22, 1,024 bytes is given as 
the data size of the TKI so that each TKI in the present 
embodiment is 1,024 bytes long. so 

{17-5_22-5} TKI_LNK_PTR 

[0126] The TKIN of the TKI to which the present TKI 
is linked is written in the "TKI_LNK_PTR". The following 55 
describes such links between TKIs. 
[0127] When a track is composed of a plurality of 
AOBs which are recorded in a plurality of AOB files, 
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these AOB files will be managed as a single track by 
linking the plurality of TKIs that correspond to these 
AOB files. To link a plurality of TKIs, it is necessary to 
show the TKI of the AOB file that follows after the AOB 
file of the present TKI. Accordingly, the TKIN of the TKI 
that follows the present TKI is written in TKI_LNK_PTR. 

{17-5_22-6_19} TRI_LNK_PTR 

[0128] The following describes the settings made 
for the TKI_LNK_PTR in the eight TKIs shown in FIG. 
19. The track information numbered #1 to #3 and #8 
each correspond to separate tracks, so no information is 
set in their TKI_LNK_PTR. The track information 
TKI#4,TKI#5,TKI#6,TKI#7 correspond to the four AOB 
files that compose TrackD, so that the next track infor- 
mation is indicated in the TKI_LNK_PTR of these TKIs. 
As shown by the arrows TL4, TL5, and TL6 in FIG. 19, 
"TKI#5" is set in the TKI_LNK_PTR of TKI#4, "TKI#6" is 
set in the TKI_LNK_PTR of TKI#5, and "TKI#7" is set in 
the TKI_LNK_PTR ofTKI#6. 

[0129] As a result, a playback apparatus can refer 
to the TKI_LNK_PTRs given in the TKIs corresponding 
to these four AOB files and so find out that the four TKIs 
TKI#4 to TKI#7 and the four AOB files "AOB004.SA1" to 
"AOB007.SA1" compose a single track, TrackD. 

{17-5_22-7} TKLBLK_ATR 

[0130] The attributes of present TKI are written in 
the "TKI_BLK_ATR". In FIG. 22, the information shown 
within the broken lines extending form the 
TKLBLK_ATR shows the bit composition of the 
TKLBLK_ATR. In FIG. 22, the TKI_BLK_ATR is shown 
as being 16 bits long, with the bits from b3 to b15 being 
reserved for future use. The three bits from bit b2 to bO 
are used to show the attributes of the TKI. 
[0131] When one TKI corresponds to a complete 
track, the value "00b" is written in the TKI_BLK_ATR 
(this setting is hereafter referred to as "Track"). When 
several TKIs correspond to the same track, the value 
"001b" is written in the TKI_BLK_ATR of the first TKI 
(this setting is hereafter referred to as 
"Head_of_Track"), the value "010b" is written in the 
TKI_BLK_ATRs of the TKIs that correspond to AOBs in 
the middle of the track (this setting is hereafter referred 
to as "Midpoint_of_Track"), and the value "011b" is writ- 
ten in the TKI_BLK_ATR of the TKI that corresponds to 
the AOB at the end of the track (this setting is hereafter 
referred to as "End_ofJTrack"). When a TKI is unused 
but a TKI region exists, which is to say, when there is a 
deleted TKI, the value "100b" is written in the 
TKI_BLK_ATR (this setting is hereafter referred to as 
"Unused"). When a TKI is unused and no TKI region 
exists, the value "101b" is written in the TKI_BLK_ATR. 
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{17-5_22-8_19} Example Setting of the 
TKI_BLK_ATR 

[0132] The following describes the settings of the 
TKI_BLK_ATR for each TKI in the example shown in 5 
FIG. 19. 

[0133] By referring to the TKI_BLK_ATR of each 
TKI, it can be seen that the four pairs TKI#1 
("AOB001.SA1"), TKI#2 ("AOB002.SA1"), TKI#3 
("AOB003.SA1"), and TKI#8 ("AOB008.SA1") each cor- 10 
respond to separate tracks since the TKI_BLK_ATR of 
each of TKI#1, TKI#2, TKI#3, and TKI#8 is set as 
"Track". 

[0134] The TLK__BLK_ATR of TKI#4 is set at 
"Head.oLTrack", the TLK_BLK_ATR of TKI#7 is set at 15 
"End_of_Track M , and the TLK_BLK_ATR of TKI#5 and 
TKI#6 is set at "Midpoint _ofJrack". This means that 
the AOB file ("AOB004.SA1") corresponding to TKI#4 is 
the start of a track, the AOB files ("AOB005.SA1") and 
("AOB006.SAr) corresponding to TKI#5 and TKI#6 are 20 
midpoints of the track, and the AOB file ("AOB007.SA1") 
corresponding to TKI#7 is the end of a track. 
[0135] By classifying the combinations of TKI and 
corresponding AOB file in accordance with the settings 
of the TKI_BLK_ATR in the TKI, it can be seen that the 25 
combination of TKI#1 and "AOB001.SA1" composes a 
first track (TrackA). Likewise, the combination of TKI#2 
and "AOB002.SA1" composes a second track (TrackB) 
and the combination of TKi#3 and "AOB003.SA1" com- 
poses a third track (TrackC). The combination of TKI#4 30 
and "AOB004.SA1" composes the first part of the fourth 
track (TrackD), the combinations of TKI#5 with 
"AOB005.SA1" and TKI#6 with "AOB006.SA1" com- 
pose central parts of TrackD, and the combination of 
TKI#7 and "AOB007.SA1" composes the end part of 35 
TrackD. Finally, the combination of TKI#8 and 
"AOB008.SA1" composes a fifth track (TrackE). 

{17-5,22-9} TKLPB.TM 

40 

[0136] The playback period of the track (song) com- 
posed of the AOB recorded in the AOB file correspond- 
ing to a TKI is written in the "TKI_PB_TM" in the TKI. 
[0137] When a track is composed of a plurality of 
TKIs, the entire playback period of the track is written in 45 
the TKI_PB_TM of the first TKI corresponding to the 
track, while the playback period of the corresponding 
AOB is written into the second and following TKIs for the 
track. 

50 

{17-5,22-10} TKI_AOB_ATR 

[0138] The encoding conditions used when produc- 
ing an AOB, which is to say information such as (1) the 
sampling frequency at which the AOB recorded in the 55 
corresponding AOB file was sampled, (2) the transfer 
bitrate, and (3) the number of channels, is written in the 
"TKI_AOB_ATR" in a TKI. The bit composition of the 



TKI_AOB_ATR is shown within the broken lines that 
extend from the "TKI_AOB_ATR" in FIG. 22. 
[0139] In FIG. 22, the TKLAOB_ATR is composed 
of 32 bits, with the coding mode being written in the 
four-bit field from bit b16 to bit b19. When the AOB is 
encoded according to MPEG-2 AAC (with ADTS 
header), the value "0000b" is written into this field, while 
when the AOB is encoded according to MPEG-layer 3 
(MP3), the value "0001b" is written. When the AOB is 
encoded according to Windows Media Audio (WMA), 
the value "0010b" is written in this field. 
[0140] The bitrate used when encoding the AOB is 
written in the eight-bitfield between bit b15 and bit b8. 
When the AOB is encoded according to MPEG-2 AAC 
(with ADTS header), a value between "16" and "72" is 
written into this field, while when the AOB is encoded 
according to MPEG1-layer 3 (MP3), a value between 
"16" and "96" is written. When the AOB is encoded 
according to MPEG1-layer 3 (MP3) LSF, a value 
between "16" and "80" is written into this field, while 
when the AOB is encoded according to Windows Media 
Audio (WMA), a value between "8" and "16" is written. 
[0141] The sampling frequency used when encod- 
ing the AOB is written in the four-bit field between bit b7 
and bit b4. When the sampling frequency is 48kHz, the 
value "0000b" is written in this field. When the sampling 
frequency is 44.1kHz, the value is "0001b", when the 
sampling frequency is 32kHz, the value "0010b", when 
the sampling frequency is 24kHz, the value "0011b", 
when the sampling frequency is 22.05kHz, the value 
"0100b", and when the sampling frequency is 16kHz, 
the value "0101b". 

[0142] The number of channels is written in the 
three-bit field from bit b3 to bit b1. When one channel 
(i.e., monaural) is used, the value "000b" is written in 
this field, while when two channels (i.e., stereo) is used, 
the value "001b" is written in this field. 
[0143] The twelve-bit field from bit b31 to bit 20 is 
reserved for future use, as is the bit bO. 

{17-5.22-11} ISRC 

[0144] An ISRC (International Standard Recording 
Code) is written in the TKGI. In FIG. 22, the broken lines 
extending from the "ISRC" box show the content of the 
ISRC. As shown in the drawing, the ISRC is composed 
of ten bytes, with a Recording-item code (#12) being 
written into the four-bit field between bit b4 and bit b7. A 
Recording code/Recording-item code (#11) is written in 
the four-bit field between bit b8 and bit b1 1 . 
[0145] A Recording Code (ISRC#10, #9, #8) is writ- 
ten in the twefve-bit field between bit b12 and bit b23. A 
Year-of-Recording code (ISRC#6, #7) is written in the 
eight-bit field b24 and bit b31 . 

[0146] The First Owner Code (ISRC #3, #4, #5) is 
written in the six-bit field between bit b32 and bit b37, 
the six-bit field between bit b40 and bit b45, and the six- 
bit field between bit b48 and bit b53. The Country Code 



16 



31 



EP1 056 094 A1 



32 



(ISRC #1, #2, #3) is written in the six-bit field between 
bit b56 and bit b61 and the six-bit field between bit b64 
and bit b69. A one-bit Validity flag is written in a one-bit 
field composed of bit b79. A detailed description of 
ISRC can be found in ISO3901:1986 "Documentation- 5 
International Standard Recording Code (ISRC)". 

{17-5_22-12_23A-1}BIT 

[0147] The "Block Information Table (BIT)" is a table w 
for managing an AOB_BLOCK, and has the detailed 
composition shown in FIGS. 23A and 23B. 
[0148] As shown in FIG. 23A, a BIT is composed of 
a DATAJDFFSET field that occupies a region from the 
60th byte to the 63rd byte, an SZ_DATA field that occu- 15 
pies a region from the 64th byte to the 67th byte, a 
TMSRTE.Ns field that occupies a region from the 68th 
byte to the 71st byte, an FNs_1st_TMSRTE field that 
occupies a region from the 72nd byte to the 73rd byte, 
an FNs.LasLTMSRTE that occupies a region from the 20 
74th byte to the 75th byte, an FNs_Middle_TMSRTE 
field that occupies a region from the 76th byte to the 
77th byte, and a TIMEJ.ENGTH field that occupies a 
region from the 78th byte to the 79th byte. 
[0149] Each of these, fields is described in detail 25 
below. 

{1 7-5.22-1 2_23A-2} DATA.Offset 

[0150] The relative address of the start of an 30 
AOB_BLOCK from the boundary between clusters is 
written in the "DATA_OFFSET" as a value given in byte 
units. This expresses the size of an invalid area 
between an AOB and the AOB_BLOCK. As one exam- 
ple, when a user records a radio broadcast on a flash 35 
memory card 31 as AOBs and wishes to delete an intro 
part of a track over which a DJ has spoken, the 
DATA_OFFSET in the BIT can be set to have the track 
played back without the part including the DJ's voice. 

40 

{17-5_22-12_23A-3} SZ_DATA 

[0151] The data length of an AOB_BLOCK 
expressed in byte units is written in "SZ_DATA". By sub- 
tracting a value produced by adding the SZ_DATA to the 45 
DATA_Offset from the file size (an integer multiple of the 
cluster size), the size of the invalid area that follows the 
AOB_BLOCK can be found. 

{1 7-5.22-1 2.23A-4} TMSRTE.Ns 50 

[0152] The total number of TMSRT_Entries 
included in an AOB.BLOCK is written in 
"TMSRTE.Ns". 



{17-5.22-12.23A-5} "FNs.lst.TMSRTE", 
"FNs_Last_TMSRTE","FNs_Middle_TMSRTE" 

[0153] The number of AOB_FRAMEs included in 
the AOB.ELEMENT positioned at the start of a present 
AOB.BLOCK is written in "F N s_ 1 st_TM SRTE" . 
[0154] The number of AOB.FRAMEs included in 
the AOB.ELEMENT positioned at the end of the 
present AOB_BLOCK is written in 
"FNs_Last_TMSRTE". 

[0155] The number of AOB.FRAMEs included in 
each AOB.ELEMENT apart from those at the start and 
the end of the present AOB.BLOCK, which is to say 
AOB_ELEMENTs in the middle of the AOB.BLOCK, is 
written in "FNs_Middle_TMSRTE". 
[0156] The playback period of an AOB_ELEMENT 
is written in the format shown in FIG. 23C in the 
TIME_LENGTH" field to an accuracy in the order of 
milliseconds. As shown in FIG. 23C, the 
TIMEJ-ENGTH" field is 16-bits long. When the encod- 
ing method used in MPEG-ACC or MPEG-Layer3, the 
playback period of an AOB_ELEMENT is two seconds, 
so that the value "2000" is written in the 
TIME_LENGTH" field. 

{1 7-5,22-1 3_23B} 

[0157] FIG. 23B shows the number of 
AOB_FRAMEs indicated by "FNs_Middle_TMRTE'\ In 
the same way as FIG. 14, FIG. 23B shows the relation- 
ship between the sampling_frequency and the number 
of AOB.FRAMEs included in an AOB.ELEMENT in the 
middle of an AOB.BLOCK. 

[0158] The relationship between the 
sampling.frequency and the number of frames included 
in the AOB_ELEMENT shown in FIG. 23B is the same 
as that shown in FIG. 14, which is to say, the number of 
frames in an AOB_ELEMENT depends on the sampling 
frequency used. The number of frames written in 
"FNs_1st_TMSRTE" and "FNs_Last_TMSRTE" will fun- 
damentally be the same as the number written in 
"FNs_Middle_TMSRTE", though when an invalid area is 
present in the AOB_ELEMENTs at the start and/or end 
of an AOB_BLOCK, the values given in 
"F N s_ 1 st_TM S RTE " and/or "FNs.LasLTMSRTE" will 
differ from the value in "FNs_Middle_TMSRTE". 

{1 7-5_22-1 4_24} Example of a Stored 
AOB.ELEMENT 

[0159] FIG. 24 shows the clusters 007 to 00E that 
store the AOB composed of AOB_ELEMENT#1 to 
AOB_ELEMENT#4. The following describes the set- 
tings in the BIT when an AOB is stored as shown in FIG. 
24. AOB_ELEMENT#1 to AOB_ELEMENT#4 that are 
stored in cluster 007 to cluster 00E are indicated in FIG. 
24 by the triangular flags, with TMSRT_entries being 
set in the TKI for each of AOB_ELEMENT#1 to 
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AOB_ELEMENT#4. 

[0160] In this example, the first part of 
AOB_ELEMENT#1 at the start of the AOB is stored In 
cluster 007, while the last part of AOB_ELEMENT#4 at 
the end of the AOB is stored in cluster 00E. The 5 
AOB_ELEMENTs #1 to #4 occupy the region between 
mdO in cluster 007 to md4 in cluster O0E. As shown by 
arrow sd1 in FIG. 24, the SZ_DATA in the BIT indicates 
that AOB_ELEMENTS #1 to #4 occupy a region from 
the start of cluster 007 to the end of cluster 00E, and so 10 
does not indicate that there are the invalid areas udO 
and ud1 in clusters 007 and 00E that are not occupied 
by an AOB.ELEMENT. 

[0161] On the other hand, the AOB also includes 
the parts udO and ud1 that are present in clusters 007 15 
and OOE but are not occupied by AOB_ELEMENT#1 or 
AOB_ELEMENT#4. The DATA.Offset given in the BIT 
gives the length of the unoccupied region udO, which is 
to say, a position value for the start of the 
AOB_ELEMENT#1 relative to the start of cluster 007. 20 
[0162] In FIG. 24, the AO B_ ELEMENTS occupies 
a region from mdO in cluster 007 to md1 in cluster 008. 
[0163] This AOB_ELEMENT#1 does not occupy all 
of cluster 008, with the remaining part of the cluster 
being occupied by AOB_ELEMENT#2. 25 
AOB_ELEMENT#4 occupies a region from md3 midway 
through cluster 00C to md4 midway through cluster 
OOE. In this way, AOB_ELEMENTs may be stored 
across cluster boundaries, or in other words, 
AOB_ELEMENTs can be recorded without regard for 30 
the boundaries between clusters. The 
"FNs_1 st_TMSRTE n in the BIT shows the number of 
frames in AOB_ELEMENT#1 that is located in clusters 
007 and 008, while the "FNs_Last_TMSRTE" in the BIT 
shows the number of frames in AOB_ELEMENT#4 that 35 
is located in clusters 00C to OOE. 
[0164] In this way, AOB_ ELEMENTS can be freely 
positioned without regard for the boundaries between 
clusters. The BIT provides information showing the off- 
set from a cluster boundary to an AOB_ELEMENT and 40 
the number of frames in each AOB_ELEMENT 

{17-5_22-14_25} Use of the Number of Frames given 
in each AOB_ELEMENT (part 1) 

45 

[0165] The following describes how the number of 
frames in each AOB_ELEMENT given in the BIT is 
used. This number of frames given in the BIT Is used 
when forward or backward search is performed. As 
mentioned earlier, such operations play back 240 milli- so 
seconds of data after first skipping data with a playback 
period of two seconds. 

[0166] FIG. 25 shows how AOB_FRAME#x+1, 
which should be played back next, is set when perform- 
ing forward search starting from an AOB_FRAME#x in 55 
an AOB_ELEMENT#y in an AOB. 
[0167] FIG. 25 shows the case when a user selects 
forward search during the playback of AOB_FRAME#x 



included in AOB_ELEMENT#y. In FIG. 25, T repre- 
sents the intermittent playback period (here, 240 milli- 
seconds), 'f(t)" shows the number of frames that 
correspond to this intermittent playbackperiod, 
"skipjime" shows the length of the period that should 
be skipped between intermittent playback periods 
(here, two seconds), "f(skip_time) M shows the number of 
frames that correspond to this skip time. Intermittent 
playback is achieved by repeating the three procedures 
(1), (2), and (3) described below. 

(1) The playback apparatus refers to the 
TMSRT_entry in the TKTMSRT and jumps to the 
start of the flag symbol (AOB_ ELEMENT). 

(2) The playback apparatus performs playback for 
240 milliseconds. 

(3) The playback apparatus jumps to the start of the 
next flag symbol (AOB_ELEMENT). 

[0168] The AOB_F RAM E#x+ 1 that exists 
2s+240ms from the AOB_FRAME#x included in the 
AOB_ELEMENT#y will definitely be present in the 
AOB_ELEMENT#y+1. When specifying the 
AOB_FRAME#x+1 that is 2s+240ms from the 
AOB_FRAME#x, the first address of the next 
AOB_ELEMENT#y+1 can be immediately calculated by 
reading a TMSRT_entry from the TKTMSRT, though a 
playback apparatus cannot know the number of 
AOB_FRAMEs from the start address of the 
AOB_ELEMENT#y+1 to the AOB_FRAME#x+1 from 
the TMSRT_entry alone. 

[0169] To calculate this number of AOB_FRAMEs, It 
is necessary to subtract the total number of frames 
included in the AO B_E L E M E NT#y from the total of (1) 
the number#x showing the position of the 
AOB_FRAME#x relative to the start of the 
AOB_ELEMENT#y, (2) f(t) and (3) f(skipjime). To sim- 
plify the calculation of the relative frame position of 
AO B_ F RAM E#x+ 1 in AOB_ELEMENT#y+1, the 
M FNs_1 sLTMSRTE", "FNs_Middle_TMSRTE", and 
M FNs_Last_TMSRTE" for each AOB_ELEMENT are 
written in the BIT, as mentioned above. 

{17-5.22-1 5_26A} Use of the Number of Frames 
given in each AOB_ELEMENT (part 2) 

[0170] The number of frames written in the BIT is 
also used when the playback apparatus performs a time 
search function where playback starts at a point indi- 
cated using a time code. In FIG. 26A, shows how a play- 
back apparatus can specify the AOB_ELEMENT and 
AO B_ FRAME corresponding to the playback start time 
indicated by the user. When playback is to commence 
from a time indicated by the user, the indicated time (in 
seconds) is set in the Jmp.Entry field, and playback 
should begin from an AOB_ELEMENT#y and an 
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AOB_FRAME position x that satisfy Equation 2 given 
below. 

Equation 2 

5 

[0171] 

Jmp_Entry 

(sec)=(FNs_1st_TMSRTE+FNs_middle_TMSRTE* 
y +x)*20msec 10 

[0172] Since the "FNs_1 st_TMSRTE" and 
"FNs_Middle_TMSRTE" are provided in the BIT, these 
can be substituted into Equation 2 to calculate the 
AOB_ELEMENT#y and AOB_FRAME#x. Having done 15 
this, a playback apparatus can refer to the TKTMSRT of 
the AOB, calculate the first address of the 
AOB_ELEMENT#y+2 (which is the (y+2) th 
AOB_ELEMENT in this AOB), and start the search for 
AOB_FRAME#x from this first address. On finding the 20 
X th AOB_FRAME, the playback apparatus starts the 
playback from this frame. In this way, the playback appa- 
ratus can start the playback of data from the time indi- 
cated by Jmp_Entry (in seconds). 

[0173] In this way, a playback apparatus does not 25 
have to search for the ADTS header parts of 
AOB_FRAMEs, and only needs to perform the search in 
AOB_ELEMENTs that are given in the TMSRT_entries 
in the TKTMSRT. This means that the playback appara- 
tus can find a playback position corresponding to an 30 
indicated playback time at high speed. 
[0174] In the same way, when the Jmp_Entry is set 
and the time search function is used on a track that is 
composed of a plurality of AOBs, the playback appara- 
tus only needs to calculate an AOB_ELEMENT#y and 35 
AOB_FRAME#x that satisfy Equation 3 below. 

Equation 3 

[0175] 40 

Jmp_Entry (in seconds) = Playback period from 
AOB#1 to AOB#n + 

(FNs_1st_TMSRTE(#n+1)+FNs_mtddle_TMSRTE( 
#n+ 1 )*y+x)*20 msec 45 

[0176] The total playback period of the AOBs from 
AOB#1 to AOB#n is as follows. 

Total Playback Period from AOB#1 to AOB#n = so 
["FNs_1 st_TMSRTE" 

(#1 )+"FNs_Middle_TMSRTE" (#1)*(N umber of 
TMSRT_entries(#1)-2) + "FNs_Last_TMSRTE"(#1 ) 
+ "FNs_1st_TMSRTE" 
(#2)+("FNs_Middle_TMSRTE"(#2)*Number of 55 
TMSRT_entries (#2)-2) + 

"FNs_LasM"MSRTE"(#2) + w FNs_ 1 st_TMSRTE" 
(#3) + ("FNs_Middle_TMSRTE"(#3)*Number of 



36 

TMSRT.entries (#3) -2)+"FNs_Last_TMSRTE" 
(#3) . . . + "FNs_1sLTMSRTE"(#n)+ 
("FNs_Middle_TMSRTE" (#n) * Number of 
TMSRT_entries (#n)-2) + 

"FNs_Last_TMSRTE"(#n)] *20msec 

[0177] Having calculated an AOB#n, an 
AO B_ E LE M E NT#y, and AOB_FRAME#x that satisfy 
Equation 3, the playback apparatus refers to the 
TKTMSRT corresponding to the AOB#n+1 , searches for 
the x th AOB_FRAME from the address at which the 
(y+2) th AOB.ELEMENT (i.e., AOB_ELEMENT#y+2) is 
positioned, and starts the playback from this X th 
AOB.FRAME. 

{17-5.22-1 6.27A.B} Deletion of an AOB File and a 
TKI 

[0178] This completes the explanation of all of the 
information included in the TKI. The following describes 
how the TKI is updated in the following four cases. In the 
first case (easel), a track is deleted. In the second case 
(case2) a track is deleted and a new track is recorded. 
In the third case (case3) two out of a plurality of tracks 
are selected and combined into a single track. Finally, in 
the fourth case (case4), one track is divided to produce 
two tracks. 

[0179] The following describes easel where a track 
is deleted. 

[0180] FIGS. 27Aand 27B show the partial deletion 
of a track. The example in FIGS. 27A and 27B corre- 
sponds to the TrackManager shown in FIG. 19, and 
assumes that the user has indicated the partial deletion 
of Track B. The AOB corresponding to TrackB is 
recorded in "AOB002.SA1", which is associated with 
TKI#2. This means that the deletion of "AOB002.SA1" is 
accompanied by the setting of "Unused" into the 
TKLBLK_ATR of TKI#2. This state where 
"AOB002.SA1" has been deleted and "Unused" has 
been set into the TKI_BLK_ATR of TKI#2 is shown in 
FIG. 27B. Since "AOB002.SA1" has been deleted, the 
region that was formerly occupied by "AOB002.SA1" is 
freed to become an unused region. As mentioned 
above, the other change is that "Unused" is set in the 
TKI_BLK_ATR ofTKI#2. 

{1 7-5.22-1 7.28A.B} Assignment of TKIs when a 
new AOB is recorded 

[0181] The following describes case2 where a new 
track is recorded after the deletion of a track. 
[0182] FIG. 28A shows the TrackManager after the 
deletion of tracks has been performed several times. As 
shown in FIG. 28A, if the tracks corresponding to TKI#2. 
TKI#4, TKI#7, and TKI#8 have been deleted, then 
"Unused" is set In the TKI.BLK.ATR of these TKI. 
While AOB files are deleted in the same way as conven- 
tional data files, the TrackManager is updated by merely 



EP 1 056 094 A1 



19 



37 



EP 1 056 094 A1 



38 



setting "Unused" in the TKI_BLK_ATR of the corre- 
sponding TKI. These means that TKJs whose 
TKI_BLK_ATRs are set at "Unused" can appear at dif- 
ferent places in the TrackManager. 
[0183] FIG. 28B shows how a new TKI and AOB file 5 
are written when a TKI whose TKI_BLK_ATR is 
"Unused" is present in the TrackManager. Like in FIG. 
28A, the TKI#2, TKI#4, TKI#5, TKI#7, and TKI#8 in FIG. 
28B are set as "Unused". 

[0184] In FIG. 28B, the new track to be written is 10 
composed of four AOBs. The unused TKIs used to 
record these AOBs are determined according to the 
DPL_TK_SRPs or can be freely chosen. In the present 
example, the unused TKIs numbered TKI#2, TKI#4, 
TKI#7, and TKI#8 are used to record the TKIs for the 15 
new track. 

[0185] Since these four AOBs compose one track, 
"Head_of_Track" is set in the TKI_BLK_ATR of TKI#2, 
"Middle_of_Track" is set in the TKI_BLK_ATR of TKI#4 
and TKI#7, and "End_of_Track" is set in the 20 
TKI_BLK_ATR of TKI#8. The TKI_LNK_PTR in each of 
the four TKIs, TKI#2, TKI#4, TKI#7, and TKI#8, used to 
compose the new TrackD is set so as to show the TKI 
forming the next part of TrackD, so that as shown by the 
arrows TL2, TL4, and TL7, TKI#4 is set in the 25 
TKI_LNK_PTR of TKI#2, TKI#7 is set in the 
TKI_LNK_PTR of TKI#4, and TKI#8 is set in the 
TKI_LNK_PTR of TKI#7. 

[0186] After this, the files "AOB002.SA1", 
"AOB004.SA1", "AOB007.SA1", and "AOB008.SA1" 30 
having the same numbers as TKI#2,TKI#4,TKI#7,TKI#8 
are produced, and the four AOBs composing TrackD are 
stored in these four files. 

[0187] By appropriately setting the TKI_LNK_PTRs 
and TKI_BLK_ATRs, this fourth track TrackD can be 35 
managed using TKI#2, TKI#4, TKI#7, and TKI#8. 
[0188] As described above, when a new track is 
written onto the flash memory card 31, TKIs in the 
TrackManager that are set as "Unused" are assigned as 
the TKIs to be used for tracks that are to be newly 40 
recorded. 

{17-5_22-18_29A f B} Setting of TKI when Combining 
Two Tracks 

45 

[0189] The following describes the updating of the 
TKI when combining tracks (case3). 
[0190] FIGS. 29A and 29B show how the TKIs are 
set when two tracks are combined to produce a new 
track. The example in FIG. 29A uses the same Track- so 
Manager as FIG. 19 and shows the case when the user 
performs an editing operation to combine TrackC and 
TrackE into a single track. 

[0191] In this case, the AOBs that correspond to 
TrackC and TrackE are recorded in the AOB files 55 
"AOB003.SA1" and "AOB008.SAr which correspond 
to TKI#3 and TKI#8. so that the TKI_BLK_ATRs of 
TKI#3 and TKI#8 are rewritten. FIG. 29B shows the 



TKI_BLK_ATR of these TKIs after rewriting. In FIG. 
29A, the TKI_BLK_ATRs of TKI#3 and TKI#8 is written 
as "Track", but in FIG. 29B the TKI_BLK_ATR of TKI#3 
is rewritten to "Head_of_Track" and the TKLBLK.ATR 
of TKI#8 is rewritten as "End_of_Track". By rewriting the 
TKI_BLK_ATRs in this way, the AOB files 
"AOB003.SA1" and "AOB008.SA1" which correspond 
to TKI#3 and TKI#8 end up being treated as parts of a 
single track, the new TrackC. This operation is accom- 
panied by the TKLLNK_PTR of TKI#3 being rewritten 
to indicate TKI#8. 

[0192] It should be particularly noted here that while 
the TKI_BLK_ATRs in the TKI are rewritten, no process- 
ing is performed to physically combine the AOB files 
"AOB003.SA1" and "AOB008.SA1". This is because 
AOB files are each encrypted using different FileKeys, 
so that when combining AOB files, it would be neces- 
sary to perform two processes for each AOB file to first 
decrypt the encrypted AOB file and then to re-encrypt 
the result, resulting in an excessive processing load. 
Also, an AOB file combined in this way would be 
encrypted using a single FileKey, which would make the 
combined track less secure that the tracks used to pro- 
duce it. 

[0193] The TKI is originally designed so as to sup- 
press the size of the TKTMSRT, so that the physical 
combining of AOB files by an editing operation would 
also carry the risk of the TKI becoming too large. 
[0194] For the reasons given above, editing opera- 
tions that combine tracks leave the AOB files in their 
encrypted state and are achieved by merely changing 
the attributes given by the TKI_BLK_ATRs. 

{1 7-5.22-1 8_29A,B-1_30 f 31} Conditions That 
Should be Satisfied When Combining Tracks 

[0195] The combining of tracks is performed by 
changing the TKI_BLK_ATR attributes as described 
above, but the AOBs that are included in the combined 
tracks should satisfy the conditions given below. 
[0196] A first condition is that the AOB that is to 
compose a latter part of a new track needs to have the 
same audio attributes (audio coding mode, bitrate, sam- 
pling frequency, number of channels, etc.) as the AOB 
that is to compose the first part of the new track. If an 
AOB has different audio attributes to the preceding or 
succeeding AOB, the playback apparatus will have to 
reset the operation of the decoder, which makes seam- 
less (i.e., uninterrupted) playback of consecutive AOBs 
difficult. 

[0197] The second condition is that in the track pro- 
duced by the combining, three or more AOBs made up 
of only AOB_ELEMENTs whose number of 
AOB_FRAMEs is below the required number for an 
"FNs_Middle_TMSRTE" cannot be linked. 
[0198] AOBs are classified into two types depend- 
ing on whether at least one AOB_ELEMENT includes a 
same number of AOB_FRAMEs as the number of 
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frames stipulated for an "FNs_Middle_TMSRTE". The 
Typel AOB includes at least one AOB.ELEMENT hav- 
ing this number of AOB_FRAMEs, while the Type2 AOB 
includes no AOB_ELEMENT having this number of 
AOB_FRAMEs. 5 
[0199] In other words, AOB_ELEMENTs in a Type2 
AOB have fewer AOB_ FRAMES than 
"FNs_Middle_TMSRTE", and the second condition stip- 
ulates that three Type2 AOBs cannot be linked together. 
[0200] The reason for the second condition is as fol- 10 
lows. When the playback apparatus reads AOBs suc- 
cessively, it is preferable for a sufficient number of 
AOB_FRAMEs to accumulate in the buffer of the play- 
back apparatus, though this cannot be achieved when 
there are consecutive Type2 AOBs. In such case, an 15 
underflow is likely to occur in the buffer of the playback 
apparatus, so that uninterrupted playback by the play- 
back apparatus can no longer be guaranteed. There- 
fore, in order to avoid such underflows, the second 
condition stipulating that three or more Type2 AOBs 20 
cannot be linked continuously is used. 
[0201] FIG. 30A shows a Typel AOB, while FIG. 
30B shows two examples of Type2 AOBs. In FIG. 30B, 
both AOBs are composed of less than two 
AOB_ELEMENTs, with none of the AOB__ELEMENTs 25 
including a number of AOB_FRAMEs that is set for an 
M FNs_Middle_TMSRTE". Since the absence of an 
AOB_ELEMENT with the number of AOB_FRAMEs set 
for an "FNs_Middle_TMSRTE n is the condition by which 
an AOB is classified as a Type2 AOB, this means that all 30 
of the AOBs shown in this drawing are classified as 
Type2 AOBs. 

[0202] In FIG. 31A, a combining of 
Typel +Type2+Type2+Ty pel AOBs into a single track is 
shown. As this combining does not involve the linking of 35 
three Type2 AOBs, these AOBs may be linked to form a 
single track. 

[0203] FIG. 31 B shows the linking of 
Typel +Type2+Type2+ Type2+Type1 AOBs into a single 
track. This combining would result in there being three 40 
consecutive Type2 AOBs, and so is prohibited. 

{17-5_22-18_29A,B-1_32} Combining of Tracks with 
respect to combinations of Typel and Type2 AOBS 

45 

[0204] In the combining of AOBs into a single track 
shown in FIG. 31 A, if the last AOB in the first track is a 
Typel AOB, the combining can be performed regard- 
less of whether the first part of this track is a Typel AOB 
or a Type2 AOB. FIG. 32A shows the case where the 50 
last AOB in the first track is a Typel AOB and the first 
AOB in the next track is also a Typel AOB. FIG. 32B 
shows the case where the last AOB in the first track is a 
Typel AOB and the first AOB in the next track is a Type2 
AOB. As the second condition is satisfied in both of 55 
these cases, the illustrated tracks can be combined into 
a single track. 

[0205] When the last AOB in the first track is a 



Type2 AOB and the preceding AOB in the first track is a 
Type 1 AOB, this first track can be combined with a fol- 
lowing track that starts with a Typel AOB regardless of 
whether the first AOB in the first track is a Typel AOB or 
a Type2 AOB. 

[0206] FIG. 32C shows the case where the first 
track ends with a Typel AOB and a Type2 AOB in that 
order and the second track starts with a Typel AOB. 
FIG. 32D shows the case where the first track ends with 
a Typel AOB and a Type2 AOB in that order and the 
second track starts with a Type2 AOB and a Typel AOB 
in that order. As the second condition is satisfied in both 
of these cases, the illustrated tracks can be combined 
into a single track. 

[0207] When the first track ends with a Type2 AOB 
and the immediately preceding AOB is also a Type2 
AOB, this first track can be combined with a following 
track that starts with a Typel AOB. FIG. 32E shows the 
case where the first track ends with two Type2 AOBs 
and the second track starts with a Typel AOB. As the 
second condition is satisfied in this case, the illustrated 
tracks can be combined into a single track. In this way, 
when two tracks are to be combined, an investigation is 
performed to see whether the two tracks satisfy the first 
and second conditions and the two tracks are only com- 
bined if they are judged to satisfy these conditions. 
[0208] The following describes the updating of the 
TKI for case4 where a track is divided. 

{17-5_22-19_33A,B} Settings for the TKI When a 
Track is Divided 

[0209] FIGS. 33A and 33B show examples of when 
a single track is to be divided to produce two new tracks. 
For these examples, the content of the TrackManager is 
the same as in FIG. 27, with the user being assumed to 
have performed an editing operation that divides TrackC 
into two new tracks, TrackC and TrackF. When TrackC is 
to be divided into a new TrackC and TrackF, the AOB file 
"AOB002.SA1 M is generated corresponding to TrackF. 
FIG. 33A shows that TKI#2 is set as "Unused", with this 
TKI#2 being assigned to the newly generated AOB file 
w AOB002.SAr. 

{17-5_22-19_33A,B-1_34A,B} Updating of the Direc- 
tory Entries and the FAT Values 

[0210] When the AOB file "AOB003.SA1" is divided 
to produce "AOB002.SAr the directory entries and FAT 
values have to be updated. This updating is explained 
below. FIG. 34A shows how the SD-Audio Directory 
Entry in the SD-Audio Directory to which the AOB file 
"AOB003.SAr belongs is written before the file is 
divided. 

[021 1] The AOB file n AOB003.SAr is divided into a 
plurality of parts that are stored in clusters 007, 008, 
009. 00A . . . 00D, 00E. In this case, the first cluster 
number for the AOB file "AOB003.SA1" given in the 
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directory entry is written as "007". The values (008), 
(009), (00A) . . . (OOD), (OOE) are also written in the FAT 
values 007, 008, 009. 00A . . . OOD corresponding to the 
clusters 007, 008, 009, 00A . . . OOD. 
[0212] When the AOB file "AOB003.SA1 " is divided 5 
so that its latter part becomes the new AOB file 
"AOB002.SA1", a "filename", a 'filename extension" 
and a "number of first clusters in file" for the new AOB 
file "AOB002.SA1" are added to the SD-Audio directory 
entry. FIG. 34B shows how the SD-Audio Directory 10 
Entry in the SD-Audio Directory to which the AOB file 
"AOB003.SA1" belongs is written after the AOB file 
"AOB003.SA1" has been divided. 
[0213] In FIG. 34B, the cluster OOF stores a copy of 
cluster 00B that includes the boundary indicated by the 15 
user when dividing the file. The parts of the AOB file 
"AOB002.SA1" that follow the part included in the clus- 
ter 00B are stored in the clusters 00C, OOD, OOE as 
before. Since the first part of the AOB file 
"AOB002.SA1" is stored in the cluster OOF and the 20 
remaining parts are stored in the clusters 00C, OOD, 
OOE, "OOF" is written into the "number of first cluster in 
file" for the new AOB file "AOB002.SA1", while (00C), 
(OOD), (OOE) are written into the FAT values OOF, 00C, 
OOD, OOE corresponding to the clusters OOF, 00C, OOD, 25 
and OOE, 

{17-5_22-19_33A,B-2_35A,B} Setting of the Informa- 
tion Fields in the TKI 

30 

[0214] The following describes how the information 
fields in the TKI are set for the AOB file "AOB002.SA1" 
once this file has been obtained by updating the direc- 
tory entries and the FAT values. When generating a TKI 
for a divided track, there are two kinds of information 35 
fields in the TKI. These are (1) information that can be 
copied from the original TKI and (2) information 
obtained by updating the information in the original TKI. 
The TKTXTLDA and ISRC are the former type, while 
the BIT, the TKTMSRT and other information fields are 40 
the latter type. Since both types of information exist, the 
present embodiment generates a TKI for a divided track 
by copying the original TKI to produce a template for the 
new TKI, and then dividing/updating the TKTMSRT and 
BIT in this template and updating the remaining infor- 45 
mation fields. 

[0215] FIG. 35A shows the case where an 
AOB_FRAME in an AOB is divided. The first level in 
FIG. 35A shows the four AOB_ELEMENTs, 
AOB_ELEMENT#1, AOB_ELEMENT#2, 50 

AOB_ELEMENT#3, and AOB_ELEMENT#4. The data 
lengths of these AOB_ELEMENTs are set in the 
TKTMSRT as the four TMSRT_entries #1, #2, #3, and 
#4. If the boundary bd1 for the division is set in 
AOB_ELEMENT#2 in FIG. 35A, AOB_ELEMENT#2 is 55 
divided into a first region (1) made up of the frames 
located before the boundary bd1 and a second region 
(2) composed of the frames located after the boundary 



bd1 . FIG. 35B shows the two AOBs AOB#1 and AOB#2 
obtained by dividing the AOB midway though 
AOB_ELEMENT#2. 

{17-5_22-19_33A,B-3_36} Setting of the BIT 

[0216] FIG. 36 shows how the BIT is set when an 
AOB is divided as shown in FIG. 35. The AOB shown in 
FIG. 35 is divided at the boundary bd1 . The AOB#1 pro- 
duced by this division includes the two 
AOB_ELEMENTs AOB_ELEMENT#1 and 
AOB_ELEMENT#2, while the other AOB#2 produced 
by this division includes the three AOB_ELEMENTs, 
AOB_ELEMENT#1 , AOB_ELEMENT#2, and 
AOB_ELEMENT#3. 

[0217] In FIG. 36, these AOB.ELEMENTs have 
also been given the triangular flags to shows the set- 
tings of the TMSRT_entries included in the TKIs corre- 
sponding to these AOBs. The explanation will first focus 
on AOB#1 which is obtained by this division. 
AOB_ELEMENT#1 and AOB_ELEMENT#2 that are 
included in AOB#1 occupy cluster 007 to cluster 00A, so 
that AOB#1 is handled as being the composite of cluster 
007 to cluster 00A. AOB_ELEMENT#2 in AOB#1 has a 
data length that ends not at the end of cluster 00A, but 
at the boundary bd1 that is present within cluster 00A, 
so that the SZ_DATA for AOB#1 is given as the amount 
of data from the region mdO to the boundary bd1 in clus- 
ter 00A. The "FNs_1st_TMSRTE" for AOB#1 is the 
same as before division, while the 
"FNs_Last_TMSRTE" for AOB#1 differs from the value 
used before division in that it now indicates the number 
of frames from the start of AOB_ELEMENT#2 before 
division to the boundary bd1. 

[0218] The following describes AOB#2 which is 
obtained by this division. AOB_ELEMENT#1, 
AOB_ELEMENT#2, and AOB_ELEMENT#3 that are 
included in AOB#2 occupy cluster 00B to cluster 007. 
Cluster OOF includes a copy of the content of cluster 
00A. The reason cluster OOF stores a copy of cluster 
00A is that cluster 00A is occupied by 
AOB_ELEMENT#2 in AOB#1, so that it is necessary to 
assign a different cluster to AOB_ELEMENT#1 in 
AOB#2. 

[0219] AOB_ELEMENT#1 in AOB#2 has a data 
length that starts not at the beginning of cluster 00F, but 
at the boundary bd1 that is present within cluster OOF, 
so that the SZ_DATA for AOB#2 is given as the amount 
of data from the start of cluster 00B to a point midway 
through cluster OOE plus the data length of the part of 
cluster OOF occupied by AOB_ELEMENT#1. 
[0220] The part of AOB_ELEMENT#2 in AOB#1 
that is included in the copy of cluster 00A stored in clus- 
ter OOF needs to be excluded from AOB#2, so that the 
DATA_Offset field in the BIT of AOB#2 is set at the size 
of the part of AOB_ELEMENT#2 in AOB#1 included in 
cluster OOF. 

[0221] As can be seen from FIG. 36, the division of 
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the AOB result In only the AOB.ELEMENT that includes 
the boundary for the division being divided into two and 
in the other AOB_ELEMENTs positioned before and 
after the divided AOB_ ELEMENT remaining 
unchanged. As a result, the "FN_Last_TMSRTE" of 5 
AOB#2 is set at the same value for the 
"AO B_E L E M E NT#4 " before the division, and the 
"FNs_1st_TMSRTE" of AOB#2 is set at 
AOB_ELEMENT#1 of AOB#2, which is to say, the 
number of frames included in the part that follows the w 
boundary once AOB_ E L E M E NT#2 has been divided. 

{17-5_22-19_33A,B-4_37} Setting of the BIT 

[0222] FIG. 37 shows a more specific example of 15 
changes in the BITs as a result of the division of a track. 
The left side of FIG. 37 shows an example of the set- 
tings of the BIT before division. In this BIT, the Data Off- 
set is set as "X", the SZ_DATA is set at "52428", and the 
TMSRTE.Ns is set at "n". The FNs_1st_TMSRTE is set 20 
at "80 frames", the FNs_Middle_TMSRTE is set at "94 
frames", and the FNs_Last_TMSRTE is set at "50 
frames". 

[0223] The right side of FIG. 37 shows the settings 
of two BITs produced by the division of a track. When 25 
the AOB corresponding to the BIT on the left side of 
FIG. 37 is divided as shown in FIG. 35A, the 
Data_Offset in the BIT of the first track produced by the 
division is set at "X" like the track before division", the 
"S2_DATA" is updated to the data length "Q" from the 30 
start to the division point Q, and the TMSRTE_Ns is set 
at "k" which shows the number of TMSRT_entries from 
the first TMSRT_entry to the k lh TMSRT_entry. The 
FNs_1st_TMSRTE and FNs_Middle_TMSRTE are 
respectively set at "80" and "94" frames in the same way 35 
as the BIT before division, but since the final 
AOB_ELEMENT in the AOB of the first track produced 
by the division includes "p" AOB_FRAMES, the 
FNs_Last_TMSRTE is set at M p frames." 
[0224] In the BIT of the second track produced by 40 
the division, the "Data_Offset" is set at "R", the 
"SZ.DATA" is set at (original SZ#DATA "52428 B -data 
length up to division point Q), and the TMSRTE_Ns is 
set at "n-k+1" produced by adding one (for the kth 
TMSRT_entry that is newly added as a result of the divi- 45 
sion) to the number of TMSRT_entries from the k 01 
TMSRT.entry to the n m TMSRT.entry. 
[0225] The F N s_ M idd le_TM S RTE and 
FNs_Last_TMSRTE are set at the same values as the 
BIT before division, which is to say, "94 frames" and "50 so 
frames" respectively. 

[0226] The first AOB_ELEMENT in the AOB of this 
second track includes "94-p" AOB_FRAMEs, so that 
"94-p" is set in the FNs_1st_TMSRTE of the BIT corre- 
sponding to this track. 55 



{17-5_22-19_33A,B-5_38} Setting of the BIT 

[0227] FIG. 38 shows the TKTMSRT after division. 
The following explains the settings of the TMSRT first. 
The TMSRT of the first track includes the 
TMSRT_entries from the first TMSRT_entry of the AOB 
before division to the kth TMSRT_entry, which is to say, 
the TMSRT.entries #1 to #k. 

[0228] It should be noted here that the 
AOB_ELEMENT#k that includes the boundary for the 
division only includes region (1), so that the k m 
TMSRT_entry only includes a data size corresponding 
to this region (1). The TMSRT of the second track 
includes the TMSRT_entries from the kth TMSRT_entry 
of the AOB before division to the n lh TMSRT_entry, 
which is to say, the TMSRT_entries #k to #n. It should 
be noted here that the AOB_ELEMENT#k that includes 
the boundary for the division only includes region (2), so 
that the k 01 TMSRT_entry only includes a data size cor- 
responding to this region (2). 

[0229] The copying of the TKI is accompanied by 
the division and updating of the TKTMSRT and the BIT, 
and once the remaining information has been updated, 
the TKIs for the new tracks produced by the division will 
be complete. In the same way as when combining 
tracks, the AOB files are not decrypted, so that two 
tracks can be produced by dividing an AOB file in its 
encrypted state. Since the division of an AOB file does 
not involve decryption and re- encryption, the process- 
ing load of dividing a track can be suppressed. This 
means that tracks can be edited even by a playback 
apparatus with limited processing power, 
[0230] This completes the explanation of the TKI. 
The following describes the Playlists. 

{17-6} PlaylistManager 

[0231] As shown by the broken lines h5 in FIG. 17, 
the PlaylistManager shown is made up of 
PlaylistManagerJnformation (PLMGI) for managing the 
Playlists stored in the flash memory card 31, 
DefaulLPIaylistJnformation (DPLI) for managing all of 
the track stored in the flash memory card 31 , and Play- 
listlnformation (PLI) #1, #2, #3, #4 . . . #m. Each PLI is 
information for a user-defined Playlist. As shown by the 
broken lines h6, the DPLI is composed of 
DefaulLPIaylisLGeneralJnformation (DPLGI) and 
Default_PlaylisLTrack_Search_Pointers 
(DPL_TK_SRP) #1, #2, #3, #4. . . #m. As shown by the 
broken lines h7, each PLI is composed of 
Playlist_General_lnformation (PLGI), and 
Playtist_Track_Search_Pointers (PL_TK_SRP) #1, #2, 
#3, #4 . . . #m. 

[0232] The DPLI referred to here differs from each 
PLI in the following way. While the DPL! has to indicate 
all of the tracks stored in the flash memory card 52, a 
PLI does not have this restriction and can indicate any 
number of the tracks. This opens up various possibilities 
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for the user As representative examples, the user can 
generate Playlist_ Information Indicating only his (her) 
favorite tracks and store this Playlistjnformation in the 
flash memory card 31, or can have a playback appara- 
tus automatically generate Playlist_ Information that 
only indicates tracks of a certain genre, out of a plurality 
of tracks stored in the flash memory card 31, and store 
the resulting Playlist Information in the flash memory 
card 31. 

{17-7_18> Number of Playlists and Their Data Sizes 

[0233] As shown in FIG. 18, a maximum of 99 Play- 
lists can be stored on one flash memory card 31. The 
combined data size of the PlaylistManagerJnformation 
(PLMGI) and the Default Playlist Information (DPLI) is 
also fixed at 2,560 bytes. Each PLI has a fixed length of 
512 bytes. The "DPL.TK.SRP" included in the Default 
Playlist Information includes a "DPL.TK.ATR" and a 
"DPL.TKIN". On the other hand, the "PL.TK.SRP" 
field included in a PLI includes only a H PL_TK_SRP'\ 
The format of the DPL_TK_ATR, DPL.TKIN, and 
PL.TKIN fields is shown in FIG. 39. 

{17-8.39-1} Format of DPL.TK.SRP 

[0234] FIG. 39 A shows the format of the 
DPL.TK.SRP. In FIG. 39A, the DPL.TKIN is written in 
the 0th to 9th bits in the DPL_TK_SRP, while the 
DPL.TK.ATR is written in the 13th to 15th bits. The 
10th to 12th bits in the DPL_TK_SRP are reserved for 
future use. 

[0235] The TKI number is written in the DPL.TKIN 
that occupies the 0th to 9th bits in the DPL.TK.SRP. 
This enables a TKI to be specified. 

{17-9.39B} Format of the PL.TK.SRP 

[0236] FIG. 39B shows the format of the 
PL.TK.SRP. This is a ten-bit field in which PL.TKIN, 
which is to say, a TKI number, is written. 

{17-8.39A-2} Composition of DPL.TK.ATR 

[0237] The broken lines h51 and h52 that extend 
from the DPL.TK.ATR in FIG. 39A show an example 
setting of the DPL.TK.ATR. As can be seen from this 
drawing, the DPL.TK.ATR is set for a DPL.TK.SRP in 
the same way as TKI_BLK_ATR is set for a TKI, which 
is to say, the DPL.TK.ATR is set at one of "Track", 
"Head.of.Track" "Midpoint.of.Track", and 
"End.of.Track". 

[0238] In more detail, when the TKI indicated by the 
TKIN is used and an Audio Object (AOB) corresponding 
to one complete track is recorded in the AOB file corre- 
sponding to the indicated TKI (i.e., when the 
TKI.BLK.ATR of the TKI is "Track"), the value "00b" is 
set in the "DPL.TK.ATR". 



[0239] When the TKI indicated by the TKIN is used 
and an Audio Object (AOB) corresponding to only the 
start of a track is recorded in the AOB file corresponding 
to the indicated TKI (i.e., when the TKI.BLK.ATR of the 

5 TKI is "Head.of.Track"), the value "001b" is set in the 
"DPL.TK.ATR". When the TKI indicated by the TKIN is 
used and an Audio Object (AOB) corresponding to a 
midway part track is recorded in the AOB file corre- 
sponding to the indicated TKI (i.e., when the 

10 TKI.BLK.ATR of the TKI is "MidpoinLof.Track"), the 
value "01 0b" is set in the "DPL.TK.ATR". When the TKI 
indicated by the TKIN is used and an Audio Object 
(AOB) corresponding to an end part of a track is 
recorded in the AOB file corresponding to the indicated 

15 TKI (i.e., when the TKI.BLK.ATR of the TKI is 
"End.of.Track"), the value "011b" is set in the 
"DPL.TK.ATR". 

[0240] Conversely, when the TKI indicated by the 
TKIN is unused and the TKI region is merely estab- 

20 lished, which corresponds to when a TKI has been 
deleted (i.e., when the TKI.BLK.ATR of the TKI is 
"Unused"), the value "100b" is set in the DPL.TK.ATR. 
[0241] When the TKI indicated by the TKIN is 
unused and no TKI region has been established, which 

25 is to say, when a TKI is in an initial state, the value 
"101b" is set in the "DPL.TK.ATR". 
[0242] Since the number of a TKI is written in the 
DPL.TKIN, it is clear which of the plurality of TKI corre- 
sponds to each DPL.TK.SRP. The position of the 

30 DPL.TK.SRP in the Default.Playlist. Information 
shows when the AOB corresponding to the TKI that in 
turn corresponds to the DPL.TK.SRP will be played 
back, i.e., the ordinal position of the AOB in the 
Default.Playlist. As a result, the order of the 

35 DPL.TK.SRP items in the Default.Playlist denotes the 
order in which a plurality of tracks will be played, or in 
other words, determines the playback order of tracks. 

{17-9.40-1} Interrelationship Between the 
40 Default_Playlist_lnformation, TKI, and AOB files 

[0243] FIG, 40 shows the interrelationship between 
the Default.Playlist.lnformation, the TKI, and the AOB 
files. The second, third, and fourth levels in this drawing 

45 are the same as the first, second, and third levels in FIG. 
19, and so show a TrackManager including eight TKI 
and eight AOB files. FIG. 40 differs from FIG. 19 in that 
a box showing the Default.Playlist.lnformation is given 
on the first level. The eight small divisions shown in this 

so box show the eight DPL.TK.SRP included in the 
Default.Playlist.lnformation. The upper part of each 
division shows the DPL.TK.ATR, while the lower part 
shows the DPL.TKIN. 

[0244] As shown by the arrows DT1, DT2, DT3, 
55 DT4 . . . in FIG. 40, DPL_TK_SRP#1 and TKl#1 are 
related, as are DPL_TK.SRP#2 and TKI#2, 
DPL_TK_SRP#3 and TKI#3. and DPL.TK_SRP#4 and 
TKI#4. 
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[0245] Looking at the DPL_TK_ATR fields in the 
DPL_TK_SRR it can be seen that "Track" has been set 
for each of DPL_TK_SRP#1, DPL_TK_SRP#2, 
DPL_TK_SRP#3, and DPL_TK_SRP#8. In other words, 
the four combinations DPL_TK_SRP#1 -> $ 
TKI#1( M AOB001.SA1 M ), DPL_TK_SRP#2 -> 
TKI#2("AOB002.SA1"), 
DPL_TK_SRP#3->TKI#3("AOB003.SA1"), 
DPL_TK_SRP#8 -> TKI#8("AOB008.SA1") correspond 
to four separate tracks. 10 
[0246] Meanwhile, none of DPL_TK_SRP#4, 
DPL_TK_SRP#5, DPL_TK_SRP#6, and 

DPL_TK_SRP#7 has a DPL_TK_ATR set as "Track". 
Instead, the DPL_TK_SRP#4 of DPL_TK_ATR is set at 
"Head^oLTrack", the DPL_TK_ATR of 15 
DPL_TK_SRP#7 is set at "End_of_Track H and the 
DPL_TK_ATRs of DPL_JK_SRP#5 and 
DPL_TK_SRP#6 are set at "MidpoinLoLTrack". 
[0247] This means that TKI#4("AOB004.SA1"), 
which is related to DPL_TK_SRP#4, is the start of a 20 
track, TKI#5("AOB~005.SA1") and 

TKI#6("AOB006.SA1"), which are respectively related 
to DPL_TK_SRP#5 and DPL_TK_SRP#6, are middle 
parts of a track, and TKI#7("AOB007.SA1"), which is 
related to DPL_TK_SRP#7, is the end of a track. 25 
[0248] The DPL_TK_SRP entries in the Default- 
Playlist show in what order the AOBs corresponding to 
each TKI are to be played back. The DPL_TKINs of 
DPL_TK_SRP#1 , #2, #3, #4 ... #8 in the DefaultPlaylist 
of FIG. 40 indicate TKI#1 , #2, #3, #4 . . . #8. As shown 30 
by the arrows (1)(2)(3)(4) ... (8), the AOB file 
"AOB001.SA1" corresponding to TKI#1 will be played 
back first, H AOB002.SA1" corresponding to TKI#2 will 
be played back second, "AOB003.SA1" corresponding 
to TKI#3 will be played back third, and "AOB004.SA1" 35 
corresponding to TKI#4 will be played back fourth. 

{17-10_4f } Example Settings for the DefaultPlaylist 
and Playlistjnformation 

40 

[0249] FIG. 41 shows example settings for the 
Default. Playlist and the Playlist_ Information using the 
same notation as FIG. 40. In FIG. 41 , the box on the first 
level shows the Default. Playlist, while the three boxes 
on the second level show the PLIs. 45 
[0250] The small divisions in the box showing the 
Default_Playlist shows the eight DPL_TK_SRP values 
included in the DefaulLPIaylist, while the small divisions 
in the boxes illustrating each PLI show three or four 
PL_TK_SRP values. The setting of the TKIN of each 50 
DPL_TK_SRP included in the 

Default_Playlist_lnformation is the same as in FIG. 40. 
However, the settings of the TKIN of the PL_TK_SRP 
included in each PLI are completely different to those in 
the DPL_TK_SRP. 55 
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{17-1 0_42} Correspondence between the 
DPL_TK_SRP and the TKI 

[0251] FIG. 42 shows the correspondence between 
the DPL_TK_SRP and the TKI using the same notation 
as in FIG. 40. In FIG. 42, Playlist#1 is composed of 
PL_TK_SRP#1, #2, #3. Of these, #3 is written as the 
PL_TKIN of PL_TK_SRP#1, while #1 is written as the 
PL_TKIN of PL_TK_SRP#2 and #2 as the PL_TKIN of 
PL_TK_SRP#3. This means that when tracks are 
played back according to Playlist#1, a plurality of AOBs 
will be played back as shown by the arrows (11) (12) 
(13) in the order AOB#3, AOB#1, AOB#2. 
[0252] Playlist#2 is composed of PL_TK_SRP#1, 
#2, #3. Of these, #8 is written as the PL.TKIN of 
PL_TK_SRP#1, while #3 is written as the PL.TKIN of 
PL_TK_SRP#2 and #1 as the PL.TKIN of 
PL_TK_SRP#3. This means that when tracks are 
played back according to Playlist#2, a plurality of AOBs 
will be played back, as shown by the arrows (21) (22) 
(23) in the order AOB#8, AOB#3, AOB#1, which is to 
say, in a completely different order to Playlist#1. 
[0253] Playlist#3 is composed of PL_TK_SRP#1, 
#2, #3, #4. the PL_TKIN of these PL_TK_SRP#1 to #4 
are respectively set as #8, #4, #3, and #1. This means 
that when tracks are played back according to Playl- 
tst#3, a plurality of AOBs will be played back as follows. 
First, AOB#8 that composes TrackE is played back as 
shown by the arrow (31). Next, AOB#4. AOB#5, AOB#6, 
and AOB#7 that compose TrackD are played back as 
shown by the arrow (32). After this, AOB#3 and AOB#1 
that respectively compose TrackC and TrackA are 
played back as shown by the arrows (33) and (34). 
[0254] Of special note here is that when a track is 
composed of a plurality of TKI. only the TKI number of 
the start of the track is written into the PL_TK_SRP 
entry. In more detail, while the DPL_TK_SRP values 
given in the DefaulLPIaylisL Information specifies the 
four TKIs (TKI#4,TKI#5,TKI#6,TKI#7) that compose 
TrackD, the PL_TK_SRP given in a set of 
Playlistjnformation does not need to indicate all four 
TKIs. For this reason, PL_TK_SRP#2 in Playlist#3 only 
indicates TKI#4 out of TKI#4 to TKI#7. 
[0255] On the other hand, a DPLI including a plural- 
ity of DK_TK_SRP has a data size that is no greater 
than one sector and is always loaded into the RAM of a 
playback apparatus. When tracks are played back 
according to a Playlist, the playback apparatus refers to 
the DK_TK_SRPs that are loaded into its RAM and so 
can search for TKIs at high speed. To play back TKIs 
(AOBs) using a PL_TK_SRP that only indicates the TKI 
number of the first TKI, a playback apparatus searches 
the DPL_TK_SRP loaded in its RAM based on the TKI 
indicated by the PL_TK_SRP and judges whether the 
current track is composed of a plurality of TKI. If so, the 
playback apparatus executes the appropriate procedure 
for playing back all of the corresponding TKIs (AOBs). 
[0256] As described above, the DefaulLPIaylist and 
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a plurality of PLIs are written in the Playlist_Manager. If 
different playback orders are written in the DPL_TKINs 
and PLJTKINs of the DPL_TK_SRPs and 
PL_TK_SRPs composing such playlists, it becomes 
possible to play back AOBs in different orders. By offer- 5 
ing a variety of playback orders to the user in this way, 
the user can be given the impression of there being a 
number of music albums stored in the flash memory 
card 31. 

[0257] Of special note here is that the data size of 10 
the DPL__TK_SRP corresponding to an AOB file is small 
(at no more than two bytes), while the data size of the 
TKI corresponding to an AOB file is large (at up to 1 ,024 
bytes). When reordering the TKI in the TrackManager, a 
large number of accesses need to be made to the flash 15 
memory card 31 , but when the DPL_TK_SRPs are reor- 
dered in the Default_Playlist_ Information or a PLI, this 
can be performed with fewer accesses to the flash 
memory card 31. 

[0258] In view of this, when the navigation data is 20 
edited, the order of the DPL_TK_SRPs in the 
Default_Playlist is actively changed in accordance with 
the editing operation, while the order of the TKI in the 
TrackManager is left unchanged in spite of the editing 
operation. 25 

{17-9_40-2_43A,B> Reordering of the DPL_TK_SRP 

[0259] The following describes an editing operation 
that changes the playback order of tracks by reordering 30 
the DPL_TK_SRPs in the DefaulLPIaylist_ Information. 
FIGS. 43A and 43B show one example of the reordering 
of tracks. The settings of the DPL_TK_SRPs and TKIs 
in FIG. 43A are the same as in FIG. 40. 
[0260] In FIG. 40A, the DPL.TKIN in 35 
DPL_TK_SRP#3 is set at TKI#3, while the DPL_TKIN in 
DPL_TK_SRP#8 is set at TKI#8. The following 
describes the case when these DPL_TK_SRPs with the 
thick outlines in FIG. 40A are interchanged. 
[0261] The numbers (1)(2)(3)(4)(5)(6)(7)(8) in FIG. 40 
43B show the playback order of tracks after this editing 
operation. It should be noted here that while the play- 
back order shown in FIG. 43A is TrackA, TrackB, 
TrackC, TrackD, TrackE, in FIG. 43B the DPLJKINs of 
DPL_TK_SRP#3 and DPL_TK_SRP#8 are inter- 45 
changed in the Default_PlaylistJnformation, so that the 
tracks will be played back in the order TrackA, TrackB, 
TrackE, TrackD, TrackC. In this way, the playback order 
of tracks can be easily changed by changing the order 
of the DPL_TK_SRPs in the so 
DefauILP lay list_ Information. 

[0262] While the above explanation deals with an 
editing operation that changes the order of tracks, the 
following will describe the following four operations that 
were explained with respect to the changes in the TKIs. 55 
These operations area first case (easel) where a track 
is deleted, a second case (case2) where a new track is 
recorded, a third case (case 3) where two freely selected 



tracks are combined to produce a new track, and a 
fourth case (case4) where a track is divided to produce 
two new tracks. 

{17-9_40-3_44A,B> Deletion of a Track 

[0263] The following describes easel where a track 
is deleted. 

[0264] FIGS. 44A and 44B show how the 
Default_Playlist, TrackManager, and AOB files are 
updated when, out of the DefaultPlaylist shown in FIG. 
40, DPL_TK_SRP#2 and TKI#2 are deleted. In these 
drawings, the same part of an AOB is deleted as in FIG. 
27 that was used to describe the deletion of a TKI. As a 
result, the second, third, and fourth levels in FIG. 44A 
and 44B are the same as in FIG. 27. The difference with 
FIG. 27 is that Default_PlaylistJnformation including a 
plurality of DPL_TK_SRPs is given on the first level, in 
the same way as FIG. 40. 

[0265] The present example deals with the case 
when the user deletes TrackB composed of 
DPL_TK_SRP#2-> TKI#2("AOB002.SA1") that is 
shown with the thick outline in FIG. 44A. In this case, 
DPLJK_SRP#2 is deleted from 

Default_PlaylistJnformation and DPL_JK_SRP#3 to 
DPL_TK_SRP#8 are each moved up by one place in 
the playback order so as to fill the place in the order 
freed by the deletion of DPLJTK_SRP#2. 
[0266] When the DPL_TK_SRPs are moved up in 
this way, the final DPL_TK_SRP#8 is set as "Unused". 
On the other hand, the TKI corresponding to the deleted 
part is set as "Unused" as shown in FIGS. 27A and 27B 
without other TKIs being moved to fill the gap created by 
the deletion. Deletion of the TKI is also accompanied by 
the deletion of the AOB file "AOB002.SA1". 
[0267] In this way, DPL_TK_SRPs are moved up in 
the playback order but TKIs are not moved, so that in 
FIG. 44B only the DPL_TKINs in the DPL_TK_SRPs 
are updated. For this example, the DPL_TKIN in 
DPL_TK_SRP#2 is set so as to indicate TKI#3 as 
shown by the arrow DT11, the DPL.TKIN in 
DPL_TK_SRP#3 is set so as to indicate TKI#4 as 
shown by the arrow DT12, the DPL_TKIN in 
DPL_TK_SRP#4 is set so as to indicate TKI#5, and the 
DPL_TKIN in DPL_TK_SRP#5 is set so as to indicate 
TKI#6. The DPL.TKIN in DPL_TK_SRP#8 that has 
been set at "Unused" is set so as to indicate TKI#2, as 
shown by the arrow DT1 3. 

[0268] When a track is deleted, the DPL_TK_SRP 
used for following tracks in the playback order are 
moved up, while the TKI corresponding to the deleted 
track is set at "Unused" while remaining in its present 
position. In this way, an editing operation is not accom- 
panied by movement of TKIs, which suppresses the 
processing load when editing tracks. 
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{17-9_40-4_45A,B} Assignment of TKIs when 
Recording Tracks 

[0269] The following describes case2 when a new 
track is recorded following the partial deletion of a track. 5 
FIGS. 45A and 45B show how an operation that writes 
a new TKI and DPL_TK_SRP is performed when an 
"Unused" TKI and DPL_TK_SRP are present. 
[0270] These drawings are largely the same as 
FIGS. 28A and 28B that were used to explain the 10 
assignment of a new TKI to a TKI set at "Unused". The 
second, third, and fourth levels in FIGS. 45A and 45B , 
are the same as the first three levels in FIGS. 28A and 
28B. The difference between these drawings is that the 
first levels in FIGS. 45A and 45B show the 15 
Default_Playlist_lnformation composed of a plurality of 
DPL_TK_SRR In FIG. 45A, the DPLJTK_SRP#4 to 
DPL_TK_SRP#8 are set as "Unused". On the other 
hand, in FIG. 28 the TKI#2, TKI#4, TKI#5, TKI#7, TKI#8 
are set as "Unused". 20 
[0271] While TKIs set at "Unused" are present here 
and there in the TrackManager, the "Unused" 
DPL_TK_SRPs are positioned next to one another in 
the DefaulLPIaylistJnformation. This results from the 
used DPL_TK_SRPs being moved up in the 25 
DefaulLPIaylistJnformation as described above, while 
no such moving up is performed for TKIs. 
[0272] The following explanation describes the 
case when TrackD composed of four AOBs is written. 
The TKIs for these four AOBs are respectively written 30 
into the following "Unused" TKIs in the TrackManager: 
TKI#2; TKI#4; TK!#7; and TKI#8. 
[0273] The DPL_TK_SRPs for these four AOBs are 
written in DPL_TK_SRP#4 to DPL_TK_SRP#7 in the 
DefaulLPIaylistJnformation. Since these four AOBs 35 
compose a single track, the DPL_TK_ATR of 
DPL_TK_SRP#4 is set at "Head.oMrack", the 
DPL_TK_ATRs of DPL_TK_SRP#5 and 
DPL_TK_SRP#6 are set at M Middle_of_Track M , and the 
DPL_TK_ATR of DPL_TK_SRP#7 is set at 40 
"End_of_Track". 

[0274] The DPLJTKIN of DPL_TK_SRP#4 is set at 
TKI#2, the DPL.TKIN of DPL_TK_SRP#5 at TKI#4, the 
DPL_TKIN of DPL_TK_SRP#6 at TKI#7, and the 
DPL_TKIN of DPL_TK_SRP#7 at TKI#8. 45 
[0275] By setting the DPLJTKINs and 
DPL_TK_ATRs in this way, TKI#2, TKI#4, TKI#7 and 
TKI#8 are managed as the fourth track TrackD. 
[0276] In the above processing, a write is per- 
formed for "Unused" TKIs, though this has no effect on so 
the other TKIs TKI#1 , TKI#2, TKI#3, and TKI#4, as was 
also the case in FIGS. 28A and 28B. 

{17-9_40-5_46A,B} Case 3: Combining Tracks 

55 

[0277] The following describes the updating of the 
DefaulLPIaylistJnformation when tracks are combined 
(i.e., in case3). FIGS. 46A and 46B show one example 



of the combining of tracks. 

[0278] These drawings are largely the same as 
FIGS. 29A and 29B that were used to explain the com- 
bining of TKIs. The second, third, and fourth levels in 
FIGS. 46A and 46B are the same as the first two levels 
in FIGS. 29A and 29B. The difference between these 
figures is that the first levels in FIGS. 46A and 46B show 
DefaulLPIayiistJnformation, in which DPL_TK_SRP#8 
is set at "Unused" and is related to TKI#2 that is also set 
at "Unused". When an editing operation combining 
tracks is performed for AOB files and TKIs as shown in 
FIGS. 29A and 29B, the contents of DPl_TK_SRP#3 to 
DPL_TK_SRP#6 are each moved down by one and the 
content of DPL_TK_SRP#7 that is shown with the thick 
outline is copied into DPL_TK_SRP#3 as shown in 
FIGS. 46A and 46B. The TKIs are also updated, as 
shown in FIGS. 29A and 29B. 

{17-9_40-6__47A,B} Case4: Division of a Track 

[0279] The following describes the updating of the 
DefaulLPIaylistJnformation when a track is divided 
(case4). 

[0280] FIGS. 47A and 47B show one example of 
the division of a track. These drawings are largely the 
same as FIGS. 33A and 33B that were used to explain 
the division of TKIs. The second and third levels in 
FIGS. 47A and 47B are the same as the first two levels 
in FIGS. 33A and 33B. The difference between these 
figures is that the first level in FIGS. 47A and 47B shows 
DefaulLPIaylistJnformation, in which DPL_TK_SRP#8 
is set at "Unused" and is related to TKI#2 that is also set 
at "unused". 

[0281] If, as in FIGS. 33A and 33B, the user indi- 
cates the division of TKI#3 ( M AOB003.SA1") shown with 
the thick outline into two, the positions of 
DPL_TK_SRP#3 to DPL_TK_SRP#7 are each moved 
down by one in the order, and a DPL_TK_SRP set at 
"Unused" is moved within the 
DefaulLPIaylistJnformation to the former position of 
DPL_TK_SRP#3, 

[0282] This new DPL_TK_SRP#3 is associated 
with the TKI, TKI#2, newly produced by the division. 
The AOB file "AOB002.SA1" associated with TKI#2 
stores what was originally the latter part of the AOB file 
"AOB003.SA1". DPL_TK_SRP#2 is present before the 
DPL_TK_SRP#3 that is associated with TKI#2 and is 
associated with TKI#2 and "AOB002.SA1". 
[0283] This is to say, "AOB002.SA1" and 
"AOB003.SA1" respectively store the latter and former 
parts of the original "AOB003.SA1", with the 
DPL_TK_SRP#2 and DPL_TK_SRP#3 corresponding 
to these files indicating that these AOBs are to be 
played back in the order "AOB003.SA1" and 
"AOB002.SA1". As a result, the latter and former parts 
of the original "AOB003.SA1" will be played back in the 
order former part, latter part in accordance with the 
playback order given in the DPL_TK_SRP. 
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{17-9_40-8} Application of the Editing Processing 

[0284] By combining the above four editing proc- 
esses, a user can perform a great variety of editing 
operations. When, for example, a recorded track has an 5 
intro over which a disc jockey has talked, the user can 
first divide the track to separate the part including the 
disc jockey's voice. The user can then delete this track 
to leave the part of the track that does not include the 
disc jockey. 10 
[0285] This completes the explanation of the navi- 
gation data. The following describes a playback appara- 
tus with a suitable composition for playing back the 
navigation data and presentation data described above. 

15 

{48-1} External Appearance of the Playback Appara- 
tus 

[0286] FIG. 48 shows a portable playback appara- 
tus for the flash memory card 31 of the present inven- 20 
tion. The playback apparatus shown in FIG. 48 has an 
insertion slot for inserting the flash memory card 31, a 
key panel for receiving user indications for operations 
such as playback, forward search, backward search, 
fast forward, rewind, stop etc., and an LCD (liquid crys- 25 
tal display) panel. In terms of appearance, this playback 
apparatus resembles other kinds of portable music play- 
ers. 

[0287] The key pane! includes: 

30 

a "Playlist" key that receives the selection of a play- 
list or a track; 

a M |«" key that receives a skip operation that 
moves the playback position to a start of the current 
track; 35 
a "»|" key that receives a skip operation that 
moves the playback position to a start of the next 
track; 

a "«" key and a "»" key that respectively receive 
a backward search operation and a forward search 40 
operation enable the user to have the playback 
move quickly through the current track; 
a "Display" key that receives an operation to have 
still images stored on the flash memory card 31 dis- 
played; 45 
a "Rec" key that receives a recording operation; an 
"Audio" key for receiving user selections of the sam- 
pling frequency or of stereo or monaural is to be 
used; 

a "Mark" key that receives user indications that so 
mark positions in tracks; and 
an "Edit- key that receives user indications for the 
editing of tracks or for the input of track titles. 

{48-2} Improvements Made in This Portable Play- 55 
back Apparatus for the Flash Memory Card 31 

[0288] The differences between this portable play- 



back apparatus of the flash memory card 31 and a con- 
ventional portable music player lie in the following four 
improvements (1) to (4). 

(1) A list of playlist and tracks is shown on the LCD 
panel to allow the user to indicate the 
Default_Playlist_lnformation, a PL I, or separate 
tracks. 

(2) Keys on the key panel are assigned to the play- 
lists and/or tracks displayed on the LCD panel to 
allow the user to select a track or playlist that is to 
be played back or edited. 

(3) A time code showing a position in a track is dis- 
played on the LCD panel 5 when a track is played 
back. 

(4) A jog dial is provided to enable the user to set a 
time code for use as playback start time when using 
the time search function or as a division boundary 
when dividing a track. 

{48-2_49_50} Improvement (2) 

[0289] The following describes improvement (2) in 
detail. FIG. 49 shows one example of a display screen 
shown on the LCD panel when the user selects a playl- 
ist, while FIGs. 50A to 50E show examples of the dis- 
played content when the user selects a track. 
[0290] In FIG. 49, the ASCII character strings 
"DEFAULTPLAYLIST", "PLAYLIST#1 M , "PLAYLIST#2", 
"PLAYLIST#3", and "PLAYLIST#4" represent the 
default playlist and the four playlists stored in the flash 
memory card 31. 

[0291] Meanwhile, the ASCII character strings 
"Track#1", M Track#2'\ "Track#3", n Track#4", "Track#5" 
represent the five tracks that are indicated in the play- 
back order given by the default playlist stored in the 
flash memory card 31. In FIGS. 49 and 50A, the high- 
lighted Playlist and track show the track or Playlist that 
is currently indicated for playback or editing. 
[0292] If the user presses the "»" key when 
Track#1 is indicated for playback within a playback order 
given by the default Playlist displayed on the LCD panel, 
Track#2 will be indicated for playback within the list of 
tracks, as shown in FIG. 50B. If the user presses the 
"»" key again, Track#3 will be indicated for playback 
within the list of tracks, as shown in FIG. 50C. 
[0293] If the user presses the "«" key when 
Track#3 is indicated for playback within a playback order 
given by the default Playlist displayed on the LCD panel, 
Track#2 will be indicated for playback within the list of 
tracks, as shown in FIG. 50D. As shown in FIG. 50E, if 
the user presses the "Play" key when any of the tracks 
is indicated, the playback of the indicated track will 
begin, while if the user presses the "Edit" key, the indi- 
cated track will be selected for editing. 
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{48-3_51} Improvement (4) 

[0294] The following describes improvement (4) in 
detail. FIGS. 51 A to 51 C show an example operation of 
the jog dial. When the user rotates the jog dial by a cer- 5 
tain amount, the playback time code displayed on the 
LCD panel will be increased or decreased in accord- 
ance with this certain amount. The example in FIG. 51 A 
shows the case where the playback time code that is ini- 
tially displayed on the LCD panel is "00:00:20". w 
[0295] When the user rotates the jog dial counter- 
clockwise as shown in FIG. 51 B, the playback time code 
is reduced to "0:00:10" in keeping with the amount by 
which the jog dial was rotated. Conversely, when the 
user rotates the jog dial clockwise as shown in FIG. 15 
51 C, the playback time code is increased to "0:00:30" in 
keeping with the amount by which the jog dial was 
rotated. 

[0296] By allowing the user to change the playback 
time code in this way, the playback apparatus enables 20 
the user to indicate any playback time code in a track by 
merely rotating the jog dial. If the user then presses the 
"Play" key, AOBs will be played back starting from a 
position found according to Equation 2 and Equation 3. 
[0297] By using the jog dial during a track dividing 25 
operation, the user can make fine adjustments to the 
playback time code used as the division boundary. 

{52-1} Internal Construction of the Playback Appa- 
ratus 30 

[0298] The following describes the internal con- 
struction of the playback apparatus. This internal con- 
struction is shown in FIG. 52. 

[0299] As shown in FIG. 52, the playback apparatus 35 
includes a card connector 1 for connecting the playback 
apparatus to the flash memory card 31 , a user interface 
unit 2 that is connected to the key panel and the jog dial, 
a RAM 3, a ROM 4, a LCD panel 5 having a list frame 
for displaying a list of tracks or playlists and a playback 40 
time code frame for displaying a playback time code, an 
LCD driver 6 for driving the first LCD panel 5, a 
descrambler 7 for decrypting AOB_FRAMEs using a dif- 
ferent FileKey for each AOB file, an AAC decoder 8 for 
referring to the ADTS of an AOB_FRAME descrambled 45 
by the descrambler 7 and decoding the AOB_FRAME to 
obtain PCM data, a D/A converter 9 for D/A converting 
the PCM data and outputting the resulting analog sig- 
nals to a speaker or headphone jack, and a CPU 10 for 
performing overall control over the playback apparatus, so 
[0300] As can be understood from this hardware 
construction, the present playback apparatus has no 
special hardware elements for processing the Track- 
Manager and DefaulLPIaylistJnformation. To process 
the TrackManager and DefaulLPIaylistJnformation, a 55 
DPLI holding area 11, a PLI storing area 12, a TKI stor- 
ing area 13, a FileKey storing area 14, and a double 
buffer 15 are provided in the RAM 3, while a playback 
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control program and an editing control program are 
stored in the ROM 4. 

{52-2} DPLI Holding Area 11 

[0301] The DPLI holding area 11 is an area for con- 
tinuously holding DefaulLPIaylistJnformation that has 
been read from a flash memory card 31 connected to 
the card connector 1. 

{52_12} PLI Storing Area 12 

[0302] The PLI storing area 12 is an area that is 
reserved for storing Playlist_ Information that has been 
selected for playback by the user. 

{52-3} TKI Storing Area 13 

[0303] The TKI storing area 13 is an area that is 
reserved for storing only the TKI corresponding to the 
AOB file that is currently indicated for playback, out of 
the plurality of TKI included in the TrackManager. For 
this reason, the capacity of the TKI storing area 13 is 
equal to the data size of one TKI. 

{52-4} FileKey Storing Area 14 

[0304] The FileKey storing area 14 is an area that is 
reserved for storing only the FileKey corresponding to 
the AOB file that is currently indicated for playback, out 
of the plurality of FileKeys included in "AOBSA1 .KEY" in 
the authentication region. 

{52-5} Double Buffer 15 

[0305] The double buffer 1 5 is an input/output buffer 
that is used when an input process, which successively 
inputs cluster data (data that is stored in one cluster) 
read from the flash memory card 31, and an output 
process, which reads AOB_FRAMEs from cluster data 
and successively outputs the AOB_FRAMEs to the 
descrambler 7, are performed in parallel. 
[0306] The double buffer 15 successively frees the 
regions that were occupied by cluster data that has 
been outputted as AOB_FRAMEs and so secures 
regions for storing the next clusters to be read. This is to 
say, regions in the double buffer 15 are cyclically 
secured for storing cluster data using ring pointers. 

{52-5_53_54A,B} Input and Output by the Double 
Buffer 15 

[0307] FIG. 53 shows how input and output are per- 
formed for the double buffer 15. FIGS. 54A and 54B 
show how regions in the double buffer 15 are cyclically 
secured for storing cluster data using a ring pointers. 
[0308] The arrows pointing downward and to the 
left are pointers to write addresses for cluster data, 
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which is to say, the write pointer The arrows pointing 
upward and to the left are pointers to read addresses for 
cluster data, which is to say, the read pointer. These 
pointers are used as the ring pointer. 

{54-6.53} 

[0309] When a flash memory card 31 is connected 
to the card connector 1, cluster data in the user region 
of the flash memory card 31 is read out and stored in 
the double buffer 15 as shown by the arrows w1 and w2. 
[0310] The read cluster data is successively stored 
into the positions in the double buffer 15 shown by the 
write pointers wp1 and wp2.' 

{52-7_54A} 

[0311] Of the AOB_Frames included in the cluster 
data stored in this way, the AOB_Frames present at the 
positions ®@®@©©®®® that are succes- 
sively indicated by the read pointer are outputted one at 
a time to the descrambler 7 as shown by the arrows M , 
r2, r3, r4, r5 .... 

[0312] In the present case, the cluster data 002 and 
003 is stored in the double buffer 15 and the read posi- 
tions (D @ © ® are successively indicated by the 
read pointer, as shown in FIG. 53. When the read 
pointer reaches the read position © , ail of the 
AOB_FRAMEs included in cluster 002 will have been 
read, so that cluster 004 is read and, as shown by the 
arrow w6 in FIG. 54A, is overwritten into the region that 
was previously occupied by cluster 002. 

{52-8_54B} 

[0313] The read pointer then advances to the read 
positions © and © , and eventually reaches the read 
position @ , at which point alt of the AOB_FRAMEs 
included in cluster 003 will have been read, so that clus- 
ter 005 is read and, as shown by the arrow w7 in FIG. 
54B, is overwritten into the region that was previously 
occupied by cluster 003. 

[0314] The output of an AOB_FRAME and the over- 
writing of cluster data are repeatedly performed as 
described above, so that the AOB_FRAMEs included in 
an AOB file are all successively outputted to the 
descrambler 7 and AAC decoder 8. 

{52-9_55-58} Playback Control Program Stored in 
the ROM 4 

[0315] The following describes the playback control 
program stored in the ROM 4. 

[0316] FIG. 55 is a flowchart showing the process- 
ing in the AOB file reading procedure. FIGS. 56, 57, and 
58 are flowcharts showing the processing in the 
AOB_FRAME output procedure. 



{52-9.55-1} 

[0317] These flowcharts use the variables w, z, y, 
and x. The variable w indicates one of the plurality of 

5 DPL_TL_SRPs. The variable z indicates an AOB file 
recorded in the user region, the TKI corresponding to 
this AOB file, and the AOB included in this AOB file. The 
variable y indicates an AOB_ELEMENT included in the 
AOB#z indicated by the variable z. The variable x indi- 

10 cates an AOB.FRAME included in the 
AOB_ELEMENT#y indicated by the variable y. The fol- 
lowing first explains the processing in the AOB file read 
procedure, with reference to FIG. 55. 

15 {52-9.55-2} 

[0318] In step S1, the CPU 10 reads the Playlist- 
Manager and displays a list including the 
Default_Playlist_lnformation and the PLIs. 

20 [0319] In step S2, the CPU 10 waits for an indica- 
tion to play back AOBs in accordance with either the 
Default_PlaylistJnformation or one of the PLIs. 
[0320] When the Default_Playlist_lnformation is 
indicated, the processing moves from step S2 to step 

25 S3 where the variable w is initialized (#w<-1) and then 
to step S4 where the TKI#z indicated by the DPL.TKIN 
corresponding to DPL_TK_SRP#w in the 
Defa u lt_ PI ay I i st_ Information is specified and only this 
TKI#z is read from the flash memory card 31 and stored 

30 into the TKI storing area 1 3. 

[0321] In step S5, an AOB file#z with the same 
number as TKI#z is specified. In this way, the AOB file 
that is to be played back is finally specified. 
[0322] The specified AOB file is in an encrypted 

35 state and needs to be decrypted, so that steps S6 and 
S7 are performed. In step S6, the playback apparatus 
accesses the authentication region and reads the File- 
Key#z that is stored in a FileKey_Entry#z in the encryp- 
tion key storing file, the FileKey_Entry#z having the 

40 same number as the specified AOB file. In step S7, the 
CPU 10 sets the FileKey#z in the descrambler 7. This 
operation results in the FileKey being set in the 
descrambler 7, so that by successively inputting 
AOB_ FRAMEs included in the AOB file into the 

45 descrambler 7, the AOB_FRAMEs can be successively 
played back. 

{52-9.55-3} 

so [0323] After this, the playback apparatus succes- 
sively reads the clusters that store the AOB file. In step 
S8, the "first cluster number in the file" is specified for 
the AOB_file#z in the directory entry. In step S9, the 
CPU 10 reads the data stored in this cluster from the 

55 flash memory card 31. In step S10, the CPU 10 judges 
whether the cluster number in the FAT value is "FFF". If 
not, in step S11 the CPU reads the data stored in the 
cluster indicated by the FAT value, before returning to 



30 



59 



EP 1 056 094 A1 



60 



step S10. 

[0324] When the playback apparatus reads the data 
stored in any of the clusters and refers to the FAT value 
corresponding to this cluster, the processing in steps 
S10 and S11 will be repeated so long as the FAT value 
is not set at "FFF". This results in the playback appara- 
tus successively reading clusters indicated by the FAT 
values. When the cluster number given by a FAT value 
is "FFF", this means that all of the clusters composing 
the AOB file#z have been read, so that the processing 
advances from step S10 to step S12. 

{52-9.55-4} 

[0325] In step S1 2, the CPU 1 0 judges whether the 
variable#w matches the total number of 
DPl_TK_SRPs. If not, the processing advances to step 
S13, where the variable#W is incremented (#w<-#w+1) 
before the processing returns to step S4. In step S4, the 
playback apparatus specifies TKI#z which is indicated 
by the DPL_TKIN#w of DPL_TK_SRP#W in the 
Default_Playlist_lnformation, and writes only TKI#z into 
the TKI storing area 1 3. The TKI that was used up to this 
point will be still stored in the TKI storing area 13, 
though this current TKI will be overwritten by TKI#z that 
is newly read by the CPU 10. 

[0326] This overwriting results in only the latest TKI 
being stored in the TKI storing area 13. Once the TKI 
has been overwritten, the processing in steps S5 to S12 
is repeated for the AOB flle#z. Once this processing has 
read all of the TKI and AOB files corresponding to all of 
the DPL_TK_SRPs included in the 
Defa u lt_P lay list_ Information, the variable #z will match 
the total number of DPL_TK_SRP so that the judge- 
ment "Yes" is given in step S12 and the processing in 
this flowchart ends. 

{52-9_56_57_58} Output Processing for an 
AOB.FRAME 

[0327] In parallel with the AOB file reading proce- 
dure, the CPU 10 performs the AOB_FRAME output 
procedure in accordance with the flowcharts shown in 
FIGS. 56, 57, and 58. In these flowcharts, the variable 
"playjime" shows how long playback has been per- 
formed for a current track, which is to say, the playback 
time code. The time displayed in the playback time code 
frame on the LCD panel 5 is updated in accordance with 
changes to this playback time code. Meanwhile, the var- 
iable "play_data" represents the length of the data has 
been played back for the current track. 

{52-9,56-1} 

[0328] In step S21, the CPU 10 monitors whether 
cluster data for the AOB file#z has accumulated in the 
double buffer 15. This step S21 will be repeatedly per- 
formed until cluster data has accumulated, at which 



point the processing advances to step S22 where the 
variables x and y are initialized (#x<-1, #y<-1). After 
this, in step S23 the CPU 10 searches the clusters for 
AOB file #z and detects the AOB_FRAME#x in the 

5 AOB_ELEMENT#y that is positioned no earlier than the 
Data.Offset given in the BIT#z included in TKI#z. In this 
example, it is assumed that the seven bytes starting 
from the SZ_DATA are occupied by the ADTS header. 
By referring to the ADTS header, the data length indi- 

70 cated by the ADTS header can be recognized as audio 
data. The audio data and ADTS header are read 
together and are outputted to the descrambler 7. The 
descrambler 7 decrypts the AOB_FRAMEs, which are 
then decoded by the AAC decoder 8 and reproduced as 

15 audio. 

{52-9.56-2} 

[0329] After this detection, in step S24 the 

20 AOB_FRAME#x is outputted to the descrambler 7, and 
in step S25 the variable playjime is incremented by the 
playback period of the AOB_FRAME#x and the variable 
play_data is incremented the amount of data corre- 
sponding the AOB_FRAME#x. Since the playback time 

25 of AOB_FRAME is 20msec in the present case, 20msec 
is added to the variable "playjime". 
[0330] Once the first AOB_FRAME has been out- 
putted to the descrambler 7, in step S26 the playback 
apparatus refers to the ADTS header of 

30 AOB_FRAME#x and specifies where the next 
AOB_FRAME is. In step S27, the playback apparatus 
increments the variable#x (#x<-#x+1) and sets 
AOB_FRAME#x as the next AO B_ FRAME. In step S28, 
AOB_FRAME#x is inputted into the descrambler 7. 

35 After this, in step S29, the variable playjime is incre- 
mented by the playback period of the AOB_FRAME#x 
and the variable play_data is incremented the amount of 
data corresponding the AOB_FRAME#x. After incre- 
menting AOB_FRAME#x, in step S30 the CPU 10 

40 judges whether the variable #x has reached the value 
given in FNs_1st_TMSRTE. 

[0331] If the variable #x has not reached the value 
in FNs_1st_TMSRTE, in step S31 the playback appara- 
tus checks whether the user has pressed any key aside 

45 from the "Play" key, and then returns to step S26. The 
playback apparatus hereafter repeats the processing in 
steps S26 to S31 until the variable #x reaches the value 
in FNs_1st_TMSRTE or until the user presses any key 
aside from the "Play" key. 

so [0332] When the user presses a key aside from the 
"Play" key, the processing in this flowchart ends and 
suitable processing for the pressed key is performed. 
When the pressed key is the "Stop" key, the playback 
procedure stops, while when the pressed key is the 

55 "Pause" key, the playback is paused. 
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{52-9_57-1} 

[0333] On the other hand, when the variable #x 
reaches the value in F N s_ 1 st_TM S RTE , the judgement 
"Yes" is made In step S30, and the processing proceeds 5 
to step S32 in FIG. 57. Since all of the AOB_FRAMEs 
included in the present AOB_ELEMENT will have been 
inputted into the descrambler 7 in the processing 
between step S26 to S30, in step S32 the variable #y is 
incremented to set the next AOB.ELEMENT as the 10 
data to be processed and the variable #x is initialized 

(#y < -_#y+1 i #x<-1). 

[0334] After this, in step S33 the playback appara- 
tus refers to the TKTMSRT and calculates the first 
address of the AOB_ELEMENT#y. 15 
[0335] The playback apparatus then performs the 
procedure made up of steps S34 to S42. This procedure 
reads the AOB_FRAMEs included in an 
AOB_ELEMENT one after another, and so can be said 
to resemble the procedure made up of steps S24 to 20 
S31. The difference with the procedure made up of 
steps S24 to S31 is the condition by which the proce- 
dure made up of steps S24 to S31 ends is whether the 
variable #x has reached the value shown by 
"FNs_1st_TMSRTE", while the condition by which pro- 25 
cedure made up of steps S34 to S42 ends is whether 
the variable #x has reached the value shown by 
"FNs_Middle_TMSRTE". 

[0336] When the variable #x reaches the value 
shown by "FNs_Middle_TMSRTE", the loop procedure 30 
made up of steps S34 to S42 ends, the judgement "Yes" 
is given in step S41 and the processing advances to 
step S43. In step S43, the CPU 10 increments the vari- 
able #y and initializes the variable #x (#y<-#y+1 , #x<-1). 
After this, in step S44 the variable y judges whether the 35 
variable #y has reached a value that is equal to one less 
than the TotalTMSRT_entry_Number in the 
TMSRT_Header in the TKI#z. 

[0337] When the variable #y is lower than 
(TotalTMSRT_entry_Number-1), the 40 

AOB_ELEMENT#y is not the final AOB.ELEMENT, so 
that the processing returns from step S44 to step S32 
and the loop procedure of step S32 to step S42 is per- 
formed. When the variable #y reaches 
(TotalTM SRT_entry_N umber- 1) the read procedure can 45 
be assumed to have proceeded as far as the penulti- 
mate AOB.ELEMENT, so that the judgement "Yes" is 
given in step S44 and the processing advances to step 
S45 in FIG. 58. 

50 

{52-9.57-2} 

[0338] The procedure composed of steps S45 to 
S54 resembles the procedure composed of steps S33 
to S42 in that each of the AOB_ FRAMES in the final 55 
AOB.ELEMENT are read. 

[0339] The difference with the procedure composed 
of steps S33 to S42 is that while the loop procedure 



composed of steps S33 to S42 ends when it is judged in 
step S41 that the variable #x has reached the value in 
"FNs_Middle_TMSRTE", the loop procedure composed 
of steps S45 to S54 ends when it is judged in step S53 
that the variable #x has reached the value in 
"FNs_LasLTMSRTE" and the variable play_data show- 
ing the size of the data that has hitherto been read has 
reached the value given as "SZ_DATA". 
[0340] The procedure composed of steps S49 to 
S54 is repeated until the conditions in step S53 are sat- 
isfied, at which point the judgement "Yes" is given in 
step S53 and the processing advances to step S55. In 
step S55, the CPU 10 increments the variable #z 
(#z<-#z+1) before the processing returns to step S21 
where the CPU 10 waits for the next AOB file to accu- 
mulate in the double buffer 15. Once this happens, the 
processing advances to step S22 and the procedure 
composed of steps S22 to step S54 is repeated. This 
means that the TKI indicated by the DPL.TKIN of the 
next DPL_TK_SRP is specified and the AOB file corre- 
sponding to this TKI, which is to say, the AOB file with 
the same number as the TKI, is specified. 
[0341] After this, the playback apparatus accesses 
the authentication region and specifies the FileKey, out 
of the FileKeys in the encryption key storing file, that has 
the same number as the TKI, before reading this File- 
Key and setting it in the descrambler 7. As a result, the 
AOB_FRAMEs included in the AOB file having the 
same number as the TKI are successively read and 
played back. 

{52-9_57-3_59} Updating of the Playback Time Code 

[0342] FIGS. 59A to 59D show how the playback 
time code displayed in the playback time code display 
frame of the LCD panel 5 is increased in accordance 
with the updating of the variable playjime. In FIG. 59A, 
the playback time code is "00:00:00.000", though when 
the playback of AOB_FRAME#1 ends, the playback 
period 20msec of AOB_FRAME#1 is added to the play- 
back time code to update it to "00:00:00.020", as shown 
in FIG. 59B. When the playback of AOB_FRAME#2 
ends, the playback period 20msec of AOB_FRAME#2 is 
added to the playback time code to update it to 
"00:00:00.040", as shown in FIG. 59C. In the same way, 
when the playback of AOB_FRAME#6 ends, the play- 
back period 20msec of AOB_FRAME#6 is added to the 
playback time code to update it to "00:00:00. 120", as 
shown in FIG. 59D. 

[0343] This completes the description of the 
AOB_FRAME output procedure. 
[0344] In step S31 of the flowchart in FIG. 56, if the 
user presses a key aside from the "Play* key, the 
processing in this flowchart is terminated. The process- 
ing that accompanies a pressing of "Stop" or "Pause" 
key has already been described, though when the user 
presses one of the keys provided to have the playback 
apparatus perform special playback, the processing in 
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this flowchart, or in the flowcharts shown in FIGS. 56, 
57, or 58 is terminated and suitable processing for the 
pressed key is performed. 

[0345] The following describes the procedure exe- 
cuted by the CPU 10 (1) when performing the forward 5 
search function in response to the user pressing the 
"»" key and (2) when performing the time search func- 
tion in response to the user operating the jog dial after 
pressing the "Pause" or "Stop" key. 

10 

{52-1 0_60} Forward Search Function 

[0346] FIG. 60 is a flowchart showing the procedure 
executed by the CPU 10 when performing the forward 
search function. When the user presses the "»" key, 15 
the judgement "Yes" is given in step S31, step S42 or 
step S54 in the flowcharts in FIGS. 56, 57 and 58 and 
the CPU 10 performs the processing in the flowchart of 
FIG. 60. 

[0347] In step S61, the AOB.FRAMEs #x to 20 
#(x+f(t)-1) are inputted into the descrambler 7. Here T 
represents the intermittent playback period, f(t) repre- 
sents the number of frames corresponding to the inter- 
mittent playback period, and d(t) represents the amount 
of data corresponding to the intermittent playback 25 
period. In step S62, the variable playjime showing the 
playback elapsed time, and the variable play_data 
showing the playback data amount are respectively 
updated using intermittent playback period T, the 
number of frames f(t) corresponding to intermittent play- 30 
back period, and the amount of data d(t) corresponding 
to the intermittent playback period (x<-x+f(t), 
play_time<-play_time+t, play_data<-play_data+d(t)). 
Note that the intermittent playback period will generally 
be 240 msec (equivalent to the playback period of 35 
twelve AOB_FRAMEs). 

{52-10_60-1_61A,B} 

[0348] FIGS. 61 A and 61 B show the incrementing AO 
of the playback time code during a forward search oper- 
ation. FIG. 61 A shows the initial value of the playback 
time code, with the playback point being the 
AOB_FRAME#1 in AOB_ELEMENT#51 . 
[0349] The playback time code in this case is 45 
"00:00:01 .000". When the first to twelve AOB_ FRAMES 
have been inputted into the descrambler 7 as the inter- 
mittent playback period, the playback period of twelve 
AOB_FRAMEs (i.e., 240msec) is added to the playback 
time code so that the playback time code becomes so 
"00:00:01.240", as shown in FIG. 61 B. 

{52-10^60-2} 

[0350] After this updating, in step S63 the CPU 10 55 
compares the incremented variable #x with the total 
number of frames in AOB_ELEMENT#y and judges 
whether the incremented variable #x is within the total 



number of frames in AOB_ELEMENT#y. 
[0351] As mentioned earlier, the number of frames 
in an AOB_ELEMENT positioned at the start of an AOB 
is "FNs_1st_TMSRTE", the number of frames in an 
AOB_ELEMENT positioned in a central part of an AOB 
is "FNs_Middle_TMSRTE", and the number of frames in 
an AOB_ELEMENT positioned at the end of an AOB is 
n FNs_Last_TMSRTE". 

[0352] The CPU 10 performs the above judgement 
by comparing an appropriate one of these values with 
the variable #x. When the variable x is not within the 
present AOB_ELEMENT#y, the CPU 10 then judges in 
step S64 whether there is an AOB_ELEMENT that fol- 
lows the AOB_ELEMENT#y. 

[0353] When the AOB_ELEMENT#y is the final 
AOB.ELEMENT in an AOB_BLOCK, there will be no 
AOB.ELEMENT that follows the AOB_ELEMENT#y, so 
that the judgement "No" is given in step S64 and the 
processing in the present flowchart ends. Conversely, 
when an AOB_ELEMENT that follows the 
AOB_ELEMENT#y exists, in step S65 the variable #x is 
reduced by the number of AOB_FRAMEs in the 
AOB_ELEMENT#y and in step S66 the variable#y is 
updated (#y«-#y+1). As a result, the variable#x will now 
indicate the frame position of a frame in the next 
AOB_ELEMENT#y indicated by the updated variable 
#y. Conversely, when the variable #x indicates an 
AOB_FRAME that is present in the current 
AOB_ELEMENT (S63:Yes), the processing in steps 
S64-S66 is skipped and the processing advances to 
step S67. 

{52-10.60-3} 

[0354] After this, the variables #x, play_time, and 
play_data are updated in accordance with the intermit- 
tent skip period. The period "skipjime" that is equiva- 
lent to the intermittent skip period is two seconds, the 
number of frames that are equivalent to this skipjime is 
given as f(skipjime) and the amount of data that is 
equivalent to this skipjime is given as d(skipjime). In 
step S67, these values are used to update the variables 
#x, playjime, and play_data (#x<-#x+f(skipjime), 
playjime*- playjime+skipjime, and play_data<- 
play_data+d(skipjime)). 

{52-10_60-4_61C} 

[0355] As shown in FIG. 61C, the intermittent skip 
period is added to the variabte#x showing a frame posi- 
tion within the AOB_ELEMENT#51. When the updated 
variable #x exceeds the number of frames in 
AOB_ELEMENT#51, the variable #y is updated to indi- 
cate the next AOB_ELEMENT and the number of 
frames in the AOB_ELEMENT#51 is subtracted from 
the variable #x. As a result, the variable#x will now indi- 
cate a frame position within the AOB_ELEMENT#52 
indicated by the updated variable #y. The value 2.000 
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(=2sec) is then added to the present value 
"00:00:01.240" of the playback time code so that it 
becomes "00:00:03.240". The variable #x is updated by 
calculating (3240msec-2000msec)/20msec) to give the 
value "62", and so indicates the AOB_FRAME#62 in the 5 
AOB_ELEMENT#52. 

{52-10_60-5_61(d)} 

[0356] Once the AOB_FRAME#62 in the w 
AOB_ELEMENT#52 has been inputted into the 
descrambler 7, the playback time code is updated as 
shown in FIG. 61 D by adding "0.240" to the present 
value of "00:00:03.240" to give "00:00:03.480". 
[0357] In step S67, the variables are updated in 15 
accordance with the intermittent skip time and then the 
processing in steps S68 to S71 are performed. This 
processing in steps S68 to S71 is the same as the 
processing in steps S63 to S66 and so updates the var- 
iable^ by a number of frames that is equivalent to the 20 
intermittent skip time "skipjime", before checking 
whether the variable#x still indicates an AOB_ FRAME 
within the present AOB_ELEMENT#y. If not, the varia- 
ble #y is updated so that the next AOB_ELEMENT is set 
as the AOB_ELEMENT#y and the variable#x is con- 25 
verted so as to indicate a frame position in this next 
AOB.ELEMENT. 

[0358] Once the variables #x and #y have been in 
accordance with the intermittent playback time and 
intermittent skip time, in step S72 the CPU 10 refers to 30 
the TKTMSRT and calculates the start address for the 
AOB_ELEMENT#y. Then, in step S73, the CPU 10 
starts to search for an ADTS header starting from the 
start address of the AOB_ELEMENT#y to detect the 
AOB_FRAME#x. In step S74, the CPU 10 judges 35 
whether the user has pressed any key aside from the 
forward search key. If not, the AOB_FRAMEs from the 
AOB_FRAME#x to the AOB_FRAME#x+f(t)-1 are input- 
ted into the descrambler 7, and the processing in steps 
S62 to S73 is repeated. 40 
[0359] The above procedure increments the varia- 
bles #x and #y that indicate the AOB_FRAME#x and 
AOB_ELEMENT#y, and so advances the playback posi- 
tion. After this, if the user presses the "Play" key, the 
judgement "No" is given in FIG. 74 and the processing 45 
in the present flowchart ends. 

{52-11} Execution of the Time Search Function 

[0360] The following describes the processing per- so 
formed when the time search function is used. First, the 
tracks in the Default_PlaylistJnformation are displayed 
and the user indicates a desired track. When this track 
has been indicated and the user has operated the jog 
dial, the playback time code is updated. If the user then 55 
presses the "Play" key, the playback time code at that 
point is used to set a value in the variable "Jmp^Entry" 
in seconds. 



[0361] A judgement is then made as to whether the 
indicated track is composed of a plurality of AOBs or a 
single AOB. When the track is composed of a single 
AOB, the variables #y and #x are calculated so as to 
satisfy Equation 2. After this, a search for the 
AOB_FRAME#x is started from the address in the 
(y+2) th position in the TKTMSRT corresponding to this 
AOB. Once this AOB_FRAME#x has been found, play- 
back starts from AOB_FRAME#x. 

{52-12} 

[0362] When the track is composed of a plurality of 
AOBs, the variables #n (indicating an AOB), #y and #x 
are calculated so as to satisfy Equation 3. After this, a 
search for the AOB_FRAME#x is started from the 
address in the (y+2) th position in the TKTMSRT corre- 
sponding to AOB#n. Once this AOB_FRAME#x has 
been found, playback starts from AOB_FRAME#x. 
[0363] The following describes the case when play- 
back is commenced from an arbitrary position with an 
AOB where the "FNs_1st_TMSRTE" in the BIT is "80 
frames", "FNs_Middle_TMSRTE" in the BIT is "94 
frames", and the "FNs_Last_TMSRTE" in the BIT is "50 
frames". 

{52-13_62A,B} 

[0364] As one specific example of when the time 
search function is used, the following describes how the 
AOB_ELEMENT and frame position from which play- 
back should start are specified when a playback time 
code is indicated using the jog dial. 
[0365] As shown in FIG. 62A, the user holds the 
playback apparatus in his/her hand and rotates the jog 
dial with his/her right thumb to indicate the playback 
time code "00:04:40.000 (=280sec)". When the BIT in 
the TKI for this AOB is as shown in FIG. 62B, Equation 
2 is used as follows 



280sec=(FNs_1st_TMSRTE+(FNs_Middle_TMSR 
TE*y)+x) *20mse c 

= (80+(94*148)+8)*20msec 

so that the Equation 2 is satisfied for the values 
y=148 and x=8. 

[0366] Since y=148, the entry address of the 
AOB_ELEMENT#150 (=148+2) is obtained from the 
TKTMSRT Playback from the indicated playback time 
code 00:04:40.000(=280.00sec) can then be performed 
by starting the playback at the eighth AOB_FRAME 
from this entry address. 

{52-14_63_64_65} 

[0367] This completes the explanation of the 
processing of the CPU 1 0 in response to the user press- 



50 



55 



34 



67 



EP1 056 094 A1 



68 



ing the "Play" key. The following describes the editing 
control program stored in the ROM 4. This editing con- 
trol program is executed when the user presses the 
"Edit" key, and contains the procedures shown in FIGS. 
63, 64, and 65. The following describes the processing 5 
in this program with the flowcharts shown in these draw- 
ings. 

{52-14_63-1} Editing Control Program 

10 

[0368] When the user presses the "Edit" key, an 
interactive screen is displayed in step S101 in FIG. 63 to 
ask the user which of the three fundamental editing 
operations "deletion", "division" and "combining" is to be 
performed. In step S102, the CPU 10 judges what oper- 15 
ation has been made by the user in response to the 
interactive screen. In the present example, it is 
assumed that the "|«" and "»|" keys on the key panel 
are also used as indicating "Up" and "Down" cursor 
operations, (i.e., these keys are used as "Up" and 20 
"Down" cursor keys). When the user indicates a "dele- 
tion" operation, the processing proceeds to the loop 
procedure composed of steps S103 and S104. 
[0369] In step S103, the CPU 10 judges whether 
the user has pressed the "|«" or "»|" key. In step 25 

5104, the CPU 10 judges whether the user has pressed 
the "Edit" key. When the user has pressed the "|« H or 
"»|" key, the processing advances from step S103 to 

5105, where the indicated track is set as the track to be 
edited. On the other hand, when the user has pressed 30 
the "Edit" key, the indicated track is set as a track to be 
deleted. The processing shown in FIG. 44 is executed, 

so that the TKI_BLK_ATR of each TKI for the indicated 
track is set at "Unused" to delete the indicated track. 

35 

{52-14_63-2} Combining Process 

[0370] When the user selects the combining proc- 
ess, the processing proceeds from step S102 to the 
loop procedure composed of steps S107 to S109. In the AO 
loop procedure composed of steps S107 to S109, the 
playback apparatus receives user inputs via the "|«", 
"»| H , and "Edit" keys. When the user presses the "|«" 
or "»|" key, the processing advances from step S107 to 
step S110 where the indicated track is highlighted on 45 
the display. When the user presses the "Edit" key, the 
judgement "Yes" is given in step S108 and the process- 
ing advances to step S111. In step S111, the currently 
indicated track is set as the first track to be used in this 
editing process and the processing returns to the loop so 
procedure composed of steps S107 to S109. 
[0371] When a second track has been selected for 
editing, the judgement "Yes" is given in step S109, and 
the processing advances to step S112. In step S112, 
the CPU 1 1 0 refers to the BITs in the TKIs of the former 55 
and the latter tracks and judges what kind of AOBs 
(Typel or Type2) are present at the respective start and 
end of each of these tracks and tracks on either side of 



these tracks, if present. 

[0372] After identifying the type of each relevant 
AOB, in step S113 the CPU 10 judges whether the 
arrangement of AOBs matches a certain pattern. When 
the arrangement of AOBs matches one of the four pat- 
terns shown in FIG. 32A to 32D where it is clear that 
three Type2 AOBs will not be present consecutively 
after the combining, the former and latter tracks are 
combined into a single track in step S115. 
[0373] In the other words, the operation shown in 
FIG. 46 is performed for the TKI and DPL_TK_SRP cor- 
responding to these AOBs. By rewriting the 
TKI_BLK_ATRs in the TKIs, the plurality of tracks 
selected for editing are combined into a single track. 
When the arrangement of AOBs does not match any of 
the patterns in FIGS. 32A to 32D, meansing that there 
will be three or more Type2 AOBs after the combining, 
the CPU 10 judges that the combined track may cause 
a buffer underflow and so terminates the combining 
process. 

{52-1 4_64-1} Track Division Process 

[0374] When the user indicates that a track is to be 
divided, the processing advances from step S102 to the 
loop procedure composed of steps S1 1 6 to S1 1 7. In the 
loop procedure composed of steps S116 to S117, the 
playback apparatus receives user inputs via the "|«", 
"»r, and "Edit" keys. 

[0375] When the user presses the "|«" or "»|" key, 
the processing advances from step S1 16 to step S1 18 
where the indicated track is set as the track to be edited. 
When the user presses the "Edit" key, the judgement 
"Yes" is given in step S117 and the processing 
advances to step S119. 

[0376] In step S119, the indicated track is deter- 
mined as the track to be edited and the processing 
advances to step S120 where the playback of this track 
is commenced. In step S121, the playback apparatus 
receives a user input via the "Mark" key. 
[0377] When the user presses the "Mark" key, the 
playback of the track is paused and the processing 
advances to the loop procedure composed of steps 
S122 and S123. In step S122, the playback apparatus 
receives user operations made via the jog dial. When 
the user rotates the jog dial, the playback time code is 
updated in step S124 in accordance with the rotation of 
the jog dial. 

[0378] After this, the loop procedure composed of 
steps S122 and S123 is repeated. If the user presses 
the "Edit" key, the processing proceeds from step S123 
to step S125, where the playback time code displayed 
when the user pressed the "Edit" key is set as the divi- 
sion boundary. Note that an "Undo" function may be 
provided for this setting of the division boundary to allow 
the user to invalidate the selected division boundary. 
[0379] After this, the processing explained with ref- 
erence to FIG. 47 is executed in step S1 26 to update the 



35 



69 



EP1 056 094 A1 



70 



DPLI and TKI so as to divide the selected track. 
{52-14.65-1} Process Setting a Play list 

[0380] When the user chooses to set a Playlist, the 5 
processing switches to the procedure shown by the 
flowchart in FIG. 65. In this flowchart, the variable k 
given in this flowchart is used to indicate the position of 
a track in the playback order given by the Playlist that is 
being edited. The flowchart in FIG. 65 starts with this 10 
variable k being initialized to "1" in step S131 , before the 
processing advances to the loop procedure composed 
of steps S132 toS134. 

[0381] In the loop procedure composed of steps 
S132 to S134, the playback apparatus receives user 15 
operations made via the "|«", ,, »|", "Edit", and "Stop" 
keys. When the user presses the n |«" or "»|" key, the 
processing advances from step S132 to step S135 
where a new track is indicated in accordance with the 
pressing of the "|«" or "»|" key. If the user presses the 20 
"Edit" key, the judgement "Yes" is given in step S133 
and the processing advances to step S136. 
[0382] In step S136, the track indicated when the 
user presses the "Edit" key is selected as the kth track 
in the playback order. After this, in step S137 the varia- 25 
ble k is incremented and the processing returns to the 
loop procedure composed of steps S132 to S134. This 
procedure is repeated so that the second, third and 
fourth tracks are successively selected. If the user 
presses the "Stop" key have specified several tracks 30 
that are to be played back in the specified order as a 
new Playlist, the processing advances from step S134 
to step S138 where a PLI composed of PL_TK_SRPs 
that specify the TKIs corresponding to these tracks is 
generated. 35 

{66-1} Recording Apparatus 

[0383] The following describes one example of a 
recording apparatus for the flash memory card 31 . FIG. 40 
66 shows one example of a recording apparatus. This 
recording apparatus can be connected to the Internet, 
and is a standard personal computer that can perform 
reception when an encrypted SD-Audio directory is sent 
via communication lines to the recording apparatus by 45 
an electronic music distribution service, or when an 
audio data transport stream is sent via communication 
lines to the recording apparatus by an electronic music 
distribution service. 

50 

{67-1} Hardware Composition of the Recording 
Apparatus 

[0384] FIG. 67 shows the hardware composition of 
the present recording apparatus. 55 
[0385] As shown in FIG. 67, the recording appara- 
tus includes a card connector 21 for connecting the 
recording apparatus to the flash memory card 31, a 



RAM 22, a non-removable disk_apparatus 23 for storing 
a recording control program that performs overall con- 
trol over the recording apparatus, an A/D converter 24 
that A/D converts audio inputted via a microphone to 
produce PCM data, an ACC encoder 25 for encoding 
the PCM data in units of a fixed time and assigning 
ADTS headers to produce AOB_FRAMEs, a scrambling 
unit 26 for encrypting the AOB_FRAMEs using a differ- 
ent FileKey for each AOB_BLOCK, a modem apparatus 
27 for receiving an audio data transport stream when an 
encrypted SD-Audio directory is sent via communica- 
tion lines to the recording apparatus by an electronic 
music distribution service, or when an audio data trans- 
port stream is sent via communication lines to the 
recording apparatus by an electronic music distribution 
service, a CPU 28 for performing overall control over the 
recording apparatus, a keyboard 29 for receiving inputs 
made by the user, and a display 30. 

{67-2} Input Circuits RT1 to RT4 

[0386] When an encrypted SD-Audio directory, 
which is to be written in the data region and the authen- 
tication region, is sent via communication lines to the 
recording apparatus by an electronic music distribution 
service, the recording apparatus can write the 
encrypted SD-Audio directory into the data region and 
authentication region of the flash memory card 31 as 
soon as the encrypted SD-Audio directory has been 
properly received. 

[0387] However, (1) when an audio data transport 
stream that is not in the form of SD-Audio directory is 
sent to the recording apparatus by an electronic music 
distribution service, (2) when data is inputted into the 
recording apparatus in PCM format, or (3) when analog 
audio is recorded by the recording apparatus, the 
recording apparatus uses the following four input routes 
to write an audio data transport stream onto the flash 
memory card 31. 

[0388] As shown in FIG. 67, the four input routes 
RT1, RT2, RT3, and RT4 are used to input an audio 
data transport stream when an audio data transport 
stream is stored in the flash memory card 31 . 

{67-3} Input Route RT1 

[0389] The input route RT1 is used when an 
encrypted SD-Audio directory is sent via communica- 
tion lines to the recording apparatus by an electronic 
music distribution service, or when an audio data trans- 
port stream is sent via communication lines to the 
recording apparatus by an electronic music distribution 
service. In this case, the AOB_FRAMEs included in the 
transport stream are encrypted so that a different File- 
Key is used for the AOB_FRAMEs in different AOBs. 
Since there is no need to encrypt or encode an 
encrypted transport stream, the SD-Audio directory or 
audio data transport stream can be stored directly into 
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the RAM 22 in its encrypted state. 
{67-4} Input Route RT2 

[0390] Input route RT2 is used when audio is input- 5 
ted via a microphone. In this case, the audio inputted via 
the microphone is subjected to A/D conversion by the 
A/D converter 24 to produce PCM Data. The PCM data 
is then encoded by the AAC encoder 25 and assigned 
ADTS headers to produce AOB_FRAMEs. After this, 10 
the scrambling unit 26 encrypts the AOB_FRAMEs 
using a different FiteKey for each AOB_FRAMEs in dif- 
ferent AOB_FILEs to produce encrypted audio data. 
After this, the encrypted audio data is stored in the RAM 
22. 15 

{67-5} Input Route RT3 

[0391] Input route RT3 is used when PCM data 
read from a CD is inputted into the recording apparatus. 20 
Since data is inputted in PCM format, the data can be 
inputted as it is into the AAC encoder 25. This PCM data 
is encoded by the ACC encoder 25 and assigned ADTS 
headers to produce AOB_FRAMEs. 
[0392] After this, the scrambling unit 26 encrypts 25 
the AOB_FRAMEs using a different FileKey for the 
AOB_FRAMEs in different AOBs to produce encrypted 
audio data. After this, the encrypted audio data is stored 
in the RAM 22. 

30 

{67-6} Input Route RT4 

[0393] The input route RT4 is used when a trans- 
port stream inputted via one of the three input routes 
RT1 , RT2, and RT3 is written into the flash memory card 35 
31. 

[0394] This storing of audio data is accompanied by 
the generation of TKIs and 
Default_Playlist_ Information. In the same way as the 
playback apparatus, the main functioning of the record- ao 
ing apparatus is stored in the ROM. This is to say, a 
recording program that includes the characteristic 
processing of the recording apparatus, which is to say, 
the recording of AOBs, the TrackManager, and the Play- 
iistManager, is stored in the non-removable disk appa- 45 
ratus 23. 

{67-7.68} Processing of the Recording Apparatus 

[0395] The following describes the processing in 50 
the recording procedure that writes a transport stream 
in the flash memory card 31 via the Input routes RT1, 
RT2, RT3 and RT4, with reference to the flowchart in 
FIG. 68 that shows this processing. 

[0396] The variables "Frame_ Number" and 55 
"Data_Size" used in this flowchart are as follows. The 
variable Frame_Number is used to manage the total 
number of AOB_FRAMEs that have already been 
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recorded in an AOB_FILE. The variable Data_Size is 
used to manage the data size of the AOB_FRAMEs that 
have already been recorded in the AOB_FILE. 
[0397] The processing in this flowchart starts in 
step S200 with the CPU 28 generating the DefaultPlay- 
list and the TrackManager. In step S201 , the CPU 28 ini- 
tializes the variable #z (z<~1). In step S202, the CPU 28 
generates the AOB_FILE#z and stores it in the data 
region of the flash memory card 31. At this point, the 
filename, filename extension, and first cluster number 
for the AOB„FILE#z will be set in a directory entry in the 
SD_Audio Directory in the data region. After this, in step 
S203, the CPU 28 generates TKI#z and stores it in the 
TrackManager. In step S204, the CPU 28 generates the 
DPL_TK_SRP#w and stores it in the 
Default_Playlist_ Information. After this, in step S205 the 
CPU 28 initializes the variable#y (#y<-1) and in step 

5206, the CPU 28 initializes the Frame_Number and 
Data_Size (Frame_Number<-0,Data_Size<-0). 
[0398] In step S207, the CPU 28 judges whether 
the input of the audio data transport stream that should 
be written in the AOB_FILE# has ended. When the input 
of an audio data transport stream that has been 
encoded by the AAC encoder 25 and encrypted by the 
scrambling unit 26 into the RAM 22 continues and it is 
necessary to continue the writing of cluster data, the 
CPU 28 gives the judgement "No" instep S207 and the 
processing advances to step S209. 

[0399] In step S209, the CPU judges whether the 
amount of AAC audio data that has accumulated in the 
RAM 22 is at least equal to the cluster size. If so, the 
CPU 28 gives the judgement "Yes" and the processing 
advances to step S210 where an amount of AAC audio 
data equal to the cluster size is written into the flash 
memory card 31 . The processing then advances to step 
S211. 

[0400] When sufficient AAC audio data has not 
accumulated in the RAM 22, step S210 is skipped and 
the processing advances to step S211. In step S211, 
the CPU increments the Frame_Number 
(Frame_Number<-Frame_Number+1) and increases 
the value of the variable Data_Size by the data size of 
the AOB_FRAME. 

[0401] After this updating, in step S212 the CPU 28 
judges whether the value of Frame_Number has 
reached the number of frames that is set in 
n FNs_Middle_TMSRTE", the value of 
"FNs_Middle_TMSRTE M is set in accordance with the 
sampling frequency used when encoding the audio data 
transport stream. When the value of Frame_Number 
has reached the number of frames set in 
"FNs_Middle_TMSRTE", the CPU 28 gives the judge- 
ment "Yes" in step S212. if not, the CPU 28 gives the 
judgement "No" and the processing returns to step 

5207. The processing in steps S207 to S212 is there- 
fore repeated until the judgement "Yes" is given in either 
step S207 or in step S212. 

[0402] When the variable Frame_Number reaches 
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the value of "FNs_Middle_TMSRTE", the CPU 28 gives 
the judgement "Yes" in step S212 and the processing 
advances from step S212 to step S213 where 
Data.Size is stored in the TKTMSRT of TKI#z as the 
TMSRT_entry#y for the AOB_ELEMENT#y. In step 
S214, the CPU 28 increments the variable#y 
(#y<-#y+1) before checking in step S215 whether the 
variable#y has reached "252". 
[0403] The value "252" is used since this is the 
maximum number of AOB_ELEMENTs that can be 
stored in a single AOB. If the variable #y is below 252, 
the processing advances to step S216, where the CPU 
28 judges whether a silence of a predetermined length 
is present in the encoded audio, which is to say that the 
audio data has reached a gap present between tracks. 
When no such continuous silence is present, the 
processing composed of steps S206 to S215 is 
repeated. When the variable#y has reached the value 
252, or a silence of a predetermined length is present in 
the encoded audio, the judgement "Yes" is given in one 
of steps S215 and S216 and the processing advances 
to step S217 where the variable#z is incremented 
(# z< _# z +1). 

[0404] After this, the processing in steps S202 to 
S216 is repeated for the incremented variable#z. By 
repeating this processing, the CPU 28 can have AOBs 
including a plurality of AOB_ELEMENTs recorded one 
after the other into the flash memory card 31 . 
[0405] When the transfer of an audio data transport 
stream by the AAC encoder 25, the scrambling unit 26, 
and the modem apparatus 27 is complete, this means 
that the input of the audio data transport stream to be 
written into the AOB_FILE#z will also be complete, so 
that the judgement "Yes" is given in step S207 and the 
processing advances to step S208. In step S208, the 
CPU 28 stores the value of the variable Data_Size in the 
TKTMSRT of the TKI#z as the TMSRT_Entry#y for the 
AOB_ELEMENT#y. After storing the audio data accu- 
mulated in the RAM 22 in the AOB file corresponding to 
the AOB#z, the processing in this flowchart ends. 
[0406] The above processing results in an 
encrypted audio data transport stream being stored in 
the flash memory card 31. The following procedure is 
then used to store the FileKey required for decrypting 
this encrypted audio data transport stream in the 
authentication region. 

[0407] When the audio data transport stream has 
been inputted via input route RT1, the AOB file(s), the 
file storing the TKMG, the file storing the PLMG, and the 
encryption key storing file storing a different FileKey for 
each AOB are sent to the recording apparatus by a pro- 
vider of the electronic music distribution service. The 
CPU 28 receives these files and writes the AOB file(s), 
the file storing the TKMG, and the file storing the PLMG 
into the user region of the flash memory card 31 . On the 
other hand, the CPU 28 writes only the encryption key 
storing file storing a different FileKey for each AOB into 
the authentication region. 
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[0408] When the audio is inputted via the input 
route RT2 or RT3, the CPU 28 generates a different 
FileKey every time the encoding of a new AOB com- 
mences and sets the generated key in the scrambling 

5 unit 26. In addition to being used by the scrambling unit 
26 to encrypt the present AOB, this FileKey is stored fol- 
lowing the FileKey Entry in the encryption key storing 
file present in the authentication region. 
[0409] With the present embodiment describes 

w above, the files storing AOBs are encrypted using differ- 
ent encryption keys, so that if the encryption key used to 
encrypt one file is decoded and exposed, the exposed 
encryption key can only be used to decrypt a file storing 
one AOB, with such exposure having no effect on other 

15 AOBs that are stored in other files. This minimizes the 
damage caused when one encryption key is exposed. 
[0410] Note that while the above description 
focuses on an example system that is thought to be the 
most effective embodiment of the present invention, the 

20 invention is not limited to this system. Various modifica- 
tions are possible within the scope of the invention, with 
examples of the such being given as (a) to (e) below. 

(a) The above embodiment describes a semicon- 
25 ductor memory (flash memory card) as the record- 
ing medium used, though the present invention can 
be applied to other media including optical discs, 
such as DVD-RAM, or a hard disk. 

(b) In the above embodiment, the audio data was 
30 described as being in AAC format, though the 

present invention can also be applied to audio data 
in another format such as MP3 (MPEG 1 Audio 
Layer 3), Dolby-AC3, or DTS (Digital Theater Sys- 
tem). 

35 (c) While the file storing the TKMG and the file stor- 
ing the PLMG were described as being received 
from the provider of the electronic music distribution 
service in a complete form, the main information 
used to create the TKMG and PLMG can be trans- 

40 mitted together with the encryption key storing file 
that stores a different encryption key for each AOB. 
The recording apparatus may then process this 
information to obtain the TKMG and PLMG which it 
. then records in the flash memory card, 

45 (d) For ease of explanation, the recording appara- 
tus and playback apparatus were described as 
being separate devices, though a portable playback 
apparatus can be equipped with the functioning of 
the recording apparatus and a recording apparatus 

so in the form of a personal computer can be equipped 
with the functions of the playback apparatus. A side 
from the portable playback apparatus and personal 
computer recording apparatus, the functions of the 
playback apparatus and recording apparatus can 

55 also be provided to a communication device that is 
capable of downloading content from a network. 

As one example, a mobile telephone capable of 
Internet access may be provided with the functions 
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of the playback apparatus and recording apparatus 
described in the above embodiment. This mobile 
telephone may store contents downloaded via a 
wireless network in the flash memory card 31 in the 
same way as in the above embodiment. Also, while 5 
the recording apparatus described in the above 
embodiment is provided with the modem apparatus 
27 for connecting to the Internet, any other device 
capable of connecting to the Internet, such as a ter- 
minal adapter for an ISDN line, may be provided 10 
instead. 

(e) The procedures shown in the flowcharts shown 
in FIGS. 55 to 58, FIG. 60, FIG. 63 to FIG. 65, and 
FIG. 68 can be achieved by executable programs 
that may be distributed and sold having been 15 
recorded on a recording medium. This recording 
medium may be an IC card, an optical disc, a floppy 
disk, or the like, with the programs recorded on the 
recording medium being used having first been 
installed into standard computer hardware. By per- 20 
forming processing in accordance with such 
installed programs, standard computer hardware 
can perform the same functioning as the playback 
apparatus and recording apparatus described in 

the above embodiment. 25 

(f) While the above embodiment describes the case 
where a plurality of AOBs and a plurality of FileKeys 
are stored on the flash memory card 31, only one 
AOB and one FileKey need be stored. Also, it is not 
essential for the AOBs to be encrypted, so that 30 
AOBs may be stored on the flash memory card 31 

in ACC format. 

SECOND EMBODIMENT 

35 

[0411] The second embodiment of the present 
invention relates to an improvement in the storage of 
still images together with the AOB files described in the 
first embodiment. These still images are to be displayed 
when the AOB files are played back. ao 

{69-1} Hierarchical Construction of the Flash Mem- 
ory Card of the Second Embodiment 

[0412] FIG. 69 shows the hierarchical construction 45 
of the flash memory card 31 of this second embodi- 
ment. The hierarchical construction for the flash mem- 
ory card 31 described in this embodiment differs from 
that of the first embodiment in that POBs (picture 
objects) have been added to the presentation data and so 
a POBManagers has been added to the navigation 
data. POBs are pieces of still image data in JPEG (Joint 
Photographic Experts Group) format and are referred to 
by the Playlist Manager and the TrackManager. The 
POBManager is management information that 55 
describes how the POBs should be referred to by the 
PlaylistManager and the TrackManager. 



{69-1_70A-1} Composition of the User Data Area in 
the File System Layer 

[0413] Since extra information is added to the pres- 
entation data and navigation data in this embodiment, 
the internal compositions of the user data area and the 
protected area in the file system layer are modified to 
those shown in FIGS. 70A and 70B. The user data area 
shown in FIG. 70A differs from that shown in FIG. 8A in 
that files named "POBXXX.JPG" and "POBXXX.SP1" 
have been added, in addition to the POBManager file 
"POB000.POM". 

[0414] The files "POBXXX.JPG" and 
"POBXXX.SPr correspond to the POBs shown in FIG. 
69, while the file "POBOOO.POM" corresponds to the 
POBManager. The difference between the files 
"POBXXX.JPG" and "POBXXX.SPr lies in whether 
copyright protection is necessary. Files with a "JPG" 
filename extension are merely files containing still 
image data in JPEG format, while files with an "SP1" 
filename extension have been encrypted to protect the 
copyrights over the still images. Here, "SP" is an abbre- 
viation for "Secure Picture" and shows that copyright 
protection is necessary. 

[0415] Still images such as family photographs or 
memorial pictures taken by users can be recorded onto 
a flash memory card to allow users to personalize the 
stored content. Since copyright protection is generally 
unnecessary for such images, they can be recorded on 
a flash memory card in JPEG format without encryption. 
On the other hand, artist photographs and album art- 
work are generally the property of the artist or record 
label. Since there is the risk of users illegally copying 
images that have been provided by an electronic music 
distribution service, these images are recorded on a 
flash memory card as "Secure Picture" flies. 
[0416] The numbers "001", "002", "003", ...assigned 
to the filenames "POBXXX.SPr and "POBXXX.JPG" 
are the POB numbers that are assigned to individual 
picture objects (POBs). This means that picture objects 
(POBs) can be specified using POB numbers. 

{69-2_70B-1} Composition of the User Data Area in 
the File System Layer 

[0417] FIG. 70B shows the composition of the pro- 
tected area in this second embodiment. When com- 
pared with the protected area shown in FIG. 8B, the 
protected area in this second embodiment further 
includes an encryption key storing file named 
"POBSPLkey". This file stores the FileKeys used for 
decrypting the (encrypted) files "POBXXX.SPr. When 
a file "POBXXX.SPr is read, a FileKey needs to be 
extracted from this encryption key storing file 
"POBSPLkey". 

[0418] A server computer operated by a record 
label that uses electronic music distribution stores the 
SD_Audio directories shown in FIGS. 70A and 70B. 
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When a user orders a music content, the server compu- 
ter compresses the appropriate SD_Audio directory, 
encrypts it, and then sends it to the user who issued the 
order. 

[0419] The user's computer receives the SD_Audio 5 
directory, decrypts it, decompresses it, and so obtains 
the original SD_Audio directory. Note that the computer 
may instead download tracks (AOBs) with the accompa- 
nying still images (POBs) from the server computer, and 
then generate the SD-Audio directories shown in FIGS. 10 
70A and 70B by itself on the flash memory card 31 . 

{69-3_71A,B,C-1} Internal Composition of 
"POBXXXJPG" and "POBXXX.SPI" Files 

15 

[0420] The following describes the internal compo- 
sition of "POBXXXJPG" and "POBXXX.SPI" files. FIG. 
71 A shows the internal composition of a 
"POBXXXJPG" file. This file includes still image data 
that has not been encrypted, and so has the same com- 20 
position as a standard JPEG file. 
[0421] FIG. 71 B shows the internal composition of a 
"POBXXX.SPI" file. As shown in the drawing, such files 
include a POB_Header (POBJH) and encrypted still 
image data in JPEG format. 25 
[0422] The broken lines hP1 shown in FIG. 71 B 
show the internal composition of the POB_H. As shown 
in the drawing, the POB_H is composed of a two-byte 
POBJD set at the value "FFE0" to show the present file 
is a POB file, a one-byte reserved region, a one-byte 30 
POB_ATR that shows whether encrypted data is 
present in the "POBXXX.SP1", and a four-byte POB_SZ 
showing the data size of the POB. 
[0423] When encrypted data is present in the file 
"POBXXX.SP1", the value "0" is set in the POB_ATR to 35 
show the "data body exists" (i.e., the file 
"POBXXX.SP1" does not make indirect reference to 
another file). Conversely, when encrypted data is not 
present in the file "POBXXX.SPI", the file will instead 
store the file path of a file including still image data (i.e., 40 
the file "POBXXX.SPI" indirectly refers to another file). 
FIG. 71 C shows an example of a POB file that stores a 
file path instead of an encrypted data body. 
[0424] The filename "photo001.JPG" given in the 
path "¥DCIM¥Ctg_001¥photo001 JPG" indicates a file 45 
storing still image data for a digital photograph taken 
using a digital still camera. When a directory path and 
filename are indicated in a POB file in this way, indirect 
reference is made to image data stored in the file 
"photo001.JPG" with the path 50 

"¥DCIM¥Ctg_001¥photo001 JPG". In this 

"POBXXX.SPI", the POB.ATR in the POBManager is 
set at the value "1 " to show that there is "no data body". 
[0425] As one example, when the device driver of a 
digital still camera has a requirement that the still image 55 
data recorded with the camera is recorded in a particu- 
lar file in a particular directory, a POB file such as that 
shown in FIG. 71 C can specify a JPG file storing still 



image data using an indirect reference file path (in FIG. 
71 C the device driver for the digital still camera requires 
files to be stored with the path 
"¥DCIM¥Ctg_001¥photo001JPG" etc.). As a result, 
even if still image data recorded by the digital camera is 
recorded in a particular file and a particular directory in 
accordance with the needs of a device driver, such 
image data can still be displayed during playback of a 
music content. 

[0426] This completes the explanation of the pres- 
entation data in this second embodiment of the present 
invention. 

{72-1} PlayListManager and TrackManager 

[0427] The files "POBXXXJPG" and 
"POBXXX.SPI" in the presentation data are displayed 
in synchronization with the playback of tracks that was 
described in the first embodiment. To achieve such syn- 
chronous display of images with tracks, the PlaylistMan- 
ager and TrackManager of the second embodiment 
have the compositions shown in FIG. 72. FIG. 72 shows 
the detailed compositions of the PlaylistManager and 
the TrackManager in this second embodiment. The 
PlaylistManager and the TrackManager in this embodi- 
ment differ from those of the first embodiment that were 
shown in FIG. 17 is that, unlike before, the contents of 
the Default_Play!isLGeneralJnformation (DPLGI) and 
the Playlist_General_lnformation (PLGI) are clearly 
shown, and that the TKI_POB_ATR and twenty 
TKI_POB_SRPs are newly provided in the TKGI. 

{72-2} DPLGI 

[0428] As shown by the broken lines h61, the 
Default_Playlist_GeneralJnformation (DPLGI) includes 
a DPLIJD field in which a unique identifier for the DPLI 
is written, a DPLI_TK_Ns field in which the number of 
tracks referred to by the DPLI is written, a DPLI_PB_TM 
field in which the total playback time of all of the tracks 
referred to by the default playlist is written in millisecond 
units, a DPLI_POB_ATR field, and sixty 
DPLI_POB_SRP fields. 

{72-3} PLGI 

[0429] As shown by the broken lines h62, each 
piece of Playlist_GeneralJnfbrrnation (PLGI) is com- 
posed of a PLIJD field in which a unique identifier for 
the PLI is written, a PLI_TK_Ns field in which the 
number of tracks (where the maximum is "99") referred 
to by the PLI is written, a PLI_PB_TM field in which the 
total playback time of all of the tracks referred to by the 
playlist is written in millisecond units, a PLI_POB_ATR 
field, and twenty PLI_POB_SRP fields. 
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{72-4_73} Overview of the Additions and Improve- 
ments made in the Second Embodiment 

[0430] As can be understood from the preceding 
explanation, the TKGI in this second embodiment fur- s 
ther includes two kinds of information, the 
TKI_POB_ATR and TKI_POB_SRPs. In the same way, 
the DPLGI further includes two kinds of information, the 
DPLI_POB_ATR and DPLLPOB_SRPs, and each 
PLGI further includes two kinds of information, the 10 
PU_POB_ATR and PLI_POB_SRPs. 
[0431] The TKI_POB_SRPs, PLI_POB_SRPs, and 
DPLI_POB_SRPs each have the same composition 
and are used to specify a POB. FIG. 73 shows how POB 
files, such as those shown in FIG. 70A, are specified by is 
the TKI_POB_SRPs, PLI_POB_SRPs, and 
DPLI_POB_SRPs. The following describes the data 
construction of the TKI_POB_ATR (DPI_LPOB_ATR, 
PLI_POB_ATR) and the TKI_POB_SRPs 
(DPLI_POB_SRPs, PLLPOB.SRPs). 20 

{74-1}TKI_POB_SRPs 

[0432] A TKI_POB_SRP is a field that specifies a 
POB to be displayed during the playback period of a 25 
specific AOB, out of the entire playback period of the 
tracks indicated in order for playback by the 
Default_PlaylistJnformation or a PLI. In other words, by 
setting the TKI_POB_SRP in the TrackManager, a POB 
to be displayed during a track can be specified. 30 
[0433] FIG. 74 shows the data construction of the 
TKI_POB_SRPs and TKI_POB_ATR. 
[0434] As shown in the drawing, a TKI_POB_SRP 
is composed of a "POB specifying field" (shown as the 
"POB_No." in the drawing) between the bit number b25 35 
and the bit number b16, a "Number Of Pixels" field 
between the bit number b11 and the bit number b8. a 
"Huffman Table" field between the bit number b7 and 
the bit number b6, a "Chrominance Sampling" field 
between the bit number b5 and the bit number b4, and 40 
a "Picture Coding Mode" field between the bit number 
b3 and the bit number bO. The fields between the bit 
number b12 and the bit number b15 and between the bit 
number b26 and the bit number b31 are reserved 
regions. 45 
[0435] The "POB specifying field" is used for storing 
a number between "1" and "999" as the number of the 
POB to be displayed during the playback period of the 
AOB file corresponding to this TKI. When no still image 
is to be displayed during the playback period of the AOB so 
file corresponding to this TKI, the "POB specifying field" 
is set at M 0". 

[0436] The "Picture Coding Mode" is a field that is 
used to inform a playback apparatus of the encoding 
method used for the still image specified by the "POB 55 
Specifying Field". 

[0437] The "Chrominance Sampling" field is used to 
show the ratio used for the luminance sampling and the 



80 

chrominance sampling of two colors when the still 
image specified by the "POB Specifying Field" was 
encoded. The binary value "00" is set in this field to indi- 
cate the ratio is "4:2:2", while the value "01" is set to 
indicate the ratio is "4:2:0". 

[0438] The "Huffman Table" field shows whether a 
typical Huffman table should be used when displaying 
the still image specified by the "POB Specifying Field". 
This field is set at "00" when a Huffman table should be 
used. 

[0439] The "Number Of Pixels" field is a field in 
which the size of the still image specified by the "POB 
specifying field" is written in pixels. The binary value 
"0000" is written in this field when the still image speci- 
fied by the "POB Specifying Field" is 96*96 pixels, the 
"0001" is written when the image is 640*480 pixels, and 
the value "0010" is written when the image is another 
size that is in a range of 160*120 pixels to 1800*1200 
pixels. 

[0440] The TKGI includes twenty TKI_POB_SRPs 
with this construction, so that a maximum of twenty still 
images can be displayed during the playback of a track. 
When a track is composed of several TKIs, only the 
TKI_POB_SRPs in the first TKI are valid. 

{74-2} TKI_POB_ATR 

[0441] The "TKLPOB_ATR" is provided to specify 
how the POBs specified by the twenty TKI_POB_SRPs 
in a TKGI should be displayed. The "TKI_POB_ATR" 
includes a "Display Order Mode" between bit number bO 
and bit number b1 and a "Display Timing Mode" 
between bit number b2 and bit number b3. 
[0442] The "Display Order Mode" field is set to 
show the order in which the POBs specified by the 
twenty TKI_POB_SRPs in a TKGI are to be displayed. 
In this embodiment, POBs are displayed in one of three 
modes during the playback period of an AOB. 
[0443] The first mode is called "Sequential Mode" 
and is where the POBs specified by a maximum of 
twenty TKI_POB_SRPs in a TKGI are displayed in the 
order in which the TKI_POB_SRPs are given in the 
TKGI. 

[0444] The second mode is called "Random Mode" 
and is where the POBs specified by a maximum of 
twenty TKI_POB_SRPs in a TKGI are displayed in a 
random order. 

[0445] The third mode is called "Shuffle Mode" and 
is where the POBs specified by a maximum of twenty 
TKI_POB_SRPs in a TKGI are displayed in a random 
order without repetition. 

[0446] To indicate sequential mode, the binary 
value "00" is set in the "Display Order Mode" field. Con- 
versely, the binary value "01" is set to indicate random 
mode and the binary value "10" is set to indicate shuffle 
mode. 

[0447] The "Display Timing Mode" field is set to 
show whether the display of POBs specified by a maxi- 
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mum of twenty TKI_POB_SRPs in a TKGI should be 
synchronized with the playback of the AOB file corre- 
sponding to the TKI. The mode where images are syn- 
chronized with audio is called "Slideshow Mode". 
During "Slideshow Mode", the user is unable to skip 5 
through the images being displayed without skipping 
through the audio being played back. 
[0448] On the other hand, the mode where images 
and audio are not synchronized is called "Browser 
Mode". In browser mode, the user can skip through 10 
images without skipping through the audio. 
[0449] In this way, information showing which POBs 
should be displayed during the playback of the corre- 
sponding AOB file, in what order such POBs should be 
displayed, and whether display of POBs should be syn- 15 
chronized with the playback of the corresponding AOB 
file is set in a TGK1. 

{74-3J75} Example Setting of the TKI_POB_SRPs 
included in TKI#1 to TKI#3 20 

[0450] FIG. 75 shows an example setting of the 
TKI_POB_SRPs for TKI#1 to TKI#3 included in the 
TrackManager. 

[0451] The first level in FIG. 75 shows the Track- 25 
Manager, while the second level shows nine POB files. 
The TrackManager on the first level includes eight TKIs, 
with the arrows showing which POB files are referred to 
by the TKI_POB_SRPs in these eight TKIs. 
[0452] As shown by the arrows, TKI#1 includes 30 
three TKI_POB_SRPs that specify POB001 to POB003. 
TKI#2 includes three TKI_POB_SRPs that specify 
POB004 to POB006 and TKI#3 includes three 
TKI_POB_SRPs that specify POB007 to POB009. 
[0453] In this embodiment, POB001 to POB009 are 35 
assumed to JPEG image data composed of song lyrics 
arranged onto a plain background. The words compos- 
ing the lyrics are shown using a suitable font for the 
mood of the song and can be subject to embellish- 
ments, such as the addition of bold outlines. ao 
[0454] The lowest level in FIG. 75 shows the con- 
tent of each POB. The content of POB001 to POB003 is 
the lyrics for TrackA, the content of POB004 to POB006 
is the lyrics for TrackB, and the content of POB007 to 
POB009 is the lyrics for TrackC. Since these images will 45 
be meaningless unless they are displayed during the 
playback of the corresponding tracks, the 
TKI_POB_SRPs included in the TKIs are set so that 
these images are displayed during such playback. 
[0455] The playback period of each track is the 50 
same as in FIG. 16 that was referred to in the first 
embodiment. This means that the playback period of 
"AOB001.SA1" corresponding to TKI#1 is 6.1 minutes, 
the playback period of "AOB002.SA1" corresponding to 
TKI#2 is 3.3 minutes, and the playback period of 55 
n AOB003.SAr corresponding to TKI#3 is 5.5 minutes. 
During these playback periods, the TKLPOB_SRPs 
given in the TKIs will become valid, so that a playback 



apparatus can display POBs in accordance with these 
valid TKLPOB_SRPs. 

[0456] The playback period of "AOBSA1.001" cor- 
responding toTKI#1 is 6.1 minutes, so that ifPOB001 to 
POB003 are to be displayed for the same time during 
this period, each image will be displayed for 2.03 
(=6.1/3) minutes. The playback period of 
M AOBSA2.001" corresponding to TKI#2 is 3.3 minutes, 
so that POB004 to POB006 will each be displayed for 
1.1 (=3.3/3) minutes. The playback period of 
M AOBSA3.001" corresponding to TKI#3 is 5.5 minutes, 
so that POB007 to POB009 will each be displayed for 
1.83 (=5.5/3) minutes. 

{74-4_76} Example Setting of the TKI_POB_SRPs 
included in TKI#4 to TKI#8 

[0457] FIG. 76 shows one example of the setting of 
the TKI_POB_SRPs in TKI#4 to TKI#8 included in the 
TrackManager. The first level shows the TrackManager, 
while the second level shows ten POB files. As shown 
by the arrows in the drawing, TKI#4 includes seven 
TK!_POB_SRPs that respectively specify POB010 to 
POB016. 

[0458] In the same way, TKI#8 includes three 
TKI_POB_SRPs that specify POB017 to POB019. In 
the present embodiment, POB010 to POB019, like 
POB001 to POB009, are JPEG image data composed 
of song lyrics arranged onto a plain background. The 
reason that TKI_POB_SRPs are only set for TKI#4 and 
not for any of TKI#5 to TKl#7 is that when a single track 
is composed of a plurality of TKIs, only the 
TKI_POB_SRPs in the first TKI are valid, as stated ear- 
lier. 

[0459] The content of POB01 0 to POB01 6 is the lyr- 
ics for TrackD that is shown in FIG. 16 of the first 
embodiment, while the content of POB017 to POB019 
is the lyrics for TrackE. The total playback period of 
"AOB004.SA1" to "AOB007.SAr corresponding to 
TKI#4 to TKI#7 is 30.6 minutes, so that the display 
period of each of POB010 to POB016 is 4.37 (=30.6/7) 
minutes. As a result, each POB can be displayed for the 
same period during the playback period of TrackD. 
Since the playback period of "AOBSA8.SA1" corre- 
sponding to TKI#8 is 7.0 minutes, the display period of 
each of POB017 to POB0T9 is 2.33 (=7.0/3) minutes. 

{77-1} DPLI_POB_SRP and DPLI_POB_ATR 
included in the DPLGI 

[0460] While the TKI_POB_SRPs can specify 
which POBs are to be displayed during which track, the 
DPLI_POB_SRPs given in the DPLGI specify the POBs 
that should be displayed during the playback period of a 
plurality of AOBs in accordance with the order specified 
by the DefaulLPIaylistJnformation. 
[0461] FIG. 77 shows the DPLI_POB_SRPs and 
DPI_LPOB_ATRs included in the DPLGI. As can be 
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seen from this drawing, the DPl_LPOB_SRPs and 
DPLI_POB_ATRs included in the DPLGI have the same 
data constructions as the TKLPOB_SRPs and 
TKI_POB_ATRs. 

[0462] Since the DefaulLPIaylistJnformation sets 5 
the playback order for a plurality of AOB files, the 
DPLI.POB.SRPs and DPLI_POB_ATRs given in FIG. 
77 can be set to show (1) which POBs should be dis- 
played during the playback period of the plurality of AOB 
files indicated by the playback order in the 10 
Default_PlaybackJnformation, (2) in what order such 
POBs should be displayed, and (3) whether the display 
of POBs is to be synchronized with the playback of the 
AOB corresponding to the TKIs. 

15 

{77-2_78} Example Setting of Twenty 
DPLI_POB_SRPs 

[0463] FIG. 78 shows an example setting of twenty 
DPLI_POB_SRPs included in the 20 

DefaulLPIaylistJnformation. The first level in the draw- 
ing shows the DefaulLPIaylistJnformation, with the 
inner frames showing the DPLGI and twenty 
DPLLPOB_SRPs. The second level shows the twenty 
POB files POB020 to POB039. As shown by the arrows, 25 
the twenty DPL_LPOB_SRPs respectively specify the 
twenty POB files POB020 to POB039. 
[0464] POB020 is an image used as the jacket 
image for the packaged version of the music album 
composed of TrackA to TrackE, while POB021 is a logo 30 
of the production company that produced this music 
album. POB022 to POB025 are artist photos, POB026 
to POB031 are images taken from a promotional 
(promo) video, and POB032 to POB039 are photos of 
the artist performing TrackA to TrackE during a concert. 35 
The DPLI_POB_SRPs in the 

DefaulLPIaylistJnformation are defined by the pro- 
ducer of the music contents, and so can be set so as to 
have images for the tracks represented by the music 
contents, artist photos, etc. displayed during playback. AO 
[0465] During the playback period of the AOB files 
specified by the playback order in the 
Default. Play list_ Information, the POB files specified by 
the DPLI_POB_SRPs included in the DPLGI will be dis- 
played. For the example shown in FIG. 40, the 45 
DefaulLPIaylistJnformation specifies a playback order 
for the five tracks TrackA to TrackE via the eight TKIs 
composing these tracks. Meanwhile, in the example 
shown in FIG. 78, the DPLI_POB_SRPs included in this 
Defa ult_P lay NsL Information specify twenty POB files, so 
with these specifications being valid during the 52.5- 
minute playback period of TrackA to TrackE. When this 
52.5-minute playback period is to be divided equally 
among the POB020 to POB039, each image will be dis- 
played for 2.625(=52.5/20) minutes. 55 



{77-3_79> Changes in the Foreground and Back- 
ground Images as Playback Progresses 

[0466] FIG. 79 is a timing chart showing what 
images are combined when the POBs specified by the 
DPLLPOB.SRPs included in the 

DefaulLPIaylistJnformation are used as background 
images and the POBs indicated by the TKLPOB_SRPs 
included in the TrackManager are used as foreground 
images. 

[0467] The first level in the drawing shows the same 
POBs as the second level in FIG. 78, while the second 
level shows the same POBs as the second level in 
FIGS. 75 and 76. The scale that extends horizontally 
across the top of FIG. 79 shows the playback time in 
units of one minute. The horizontal width of each POB in 
FIG. 79 therefore shows the continuous display time for 
each POB. 

[0468] By referring to the time scale in FIG. 79, it 
can be seen that during the period from the start of play- 
back the point at 6.1 minutes, POB001 to POB003 (the 
lyrics for TrackA) are displayed are successively dis- 
played as the foreground image, while POB020 (the 
jacket image), POB021 (the production company logo), 
and POB022 (an artist photo) are successively dis- 
played as the background image. 
[0469] In the playback period between the point 6.1 
minutes after the start of playback and the point 14.9 
(=6.1+3.3+5.5) minutes after the start, POB004 to 
POB009 (the lyrics to TrackB and TrackC) are succes- 
sively displayed as foreground images while POB022 to 
POB025 (artist photos) are successively displayed as 
background images. 

[0470] In the period following the point 14.9 minutes 
from the start of playback, POB010 to POB011 (the lyr- 
ics for TrackD) are successively displayed as foreground 
images while POB026 to POB028 (images taken from a 
promo video) are successively displayed as the back- 
ground image. 

{77-4_80} 

[0471] In the timing chart in FIG. 79, a combined 
image composed of POB004 (the lyrics to TrackB) in the 
foreground and POB022 (an artist photo) in the back- 
ground will be displayed starting from the point 6.1 min- 
utes after the start of playback according to the 
DefaulLPIaylistJnformation. FIG. 80 shows how the 
foreground image and background image are combined 
at this point 6.1 minutes after the start of playback 
according to the DefaulLPIaylistJnformation. 

<77-5_81} 

[0472] In the same way, a combined image com- 
posed of POB010 (the lyrics to TrackD) in the fore- 
ground and POB026 (a shot from a promo video) in the 
background will be displayed starting from the point 16 
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minutes after the start of playback according to the 
Default_Playlist_lnformation. FIG. 81 shows how the 
foreground Image and background Image are combined 
at this point 16 minutes after the start of playback 
according to the Default_PlaylistJnformation. 5 
[0473] As described above, if a combined image is 
produced by combining a POB file specified by a 
DPLLPOB_SRP in the DefaulLPIaylistJnformation as 
the foreground image and a POB file specified by a 
TKI_POB_SRP in the Default_Playlist_ Information as 10 
the background image, the lyrics to the track being 
played back can be displayed with an artist photo, an 
image from the promo video of the track, a concert 
photo, or the like. The settings of what POB files should 
be displayed at what time can also be easily changed by 15 
rewriting the TKI_POB_SRPs and DPLI_POB_SRPs in 
the TrackManager and Default. Playlist_ Information. 

{82-1} PLI_POB_SRPs and PLI.POB.ATR in a PLGI 

20 

[0474] The PI_LPOB_SRPs and PLI_POB_ATR 
included in a PLGI have the same data constructions as 
the DPLI_POB_SRPs and DPLI_POB_ATR included in 
the DPLGI, and as the TKI_POB_SRPs and 
TKI_POB_ATR in a TKI. FIG. 82 shows the 25 
PLI_POB_SRPs and Pl_LPOB_ATRs included in a 
PLGI. 

As in the first embodiment, a PLI differs from the 
DefaulLPIaylistJnformation in that it shows a user- 
defined playback order, so that the PLI_POB_SRPs and 30 
PLI_POB_ATR show which POBs should be displayed 
during the playback of the plurality of AOB files specified 
in this user-defined playback order, in what order such 
POBs should be displayed, and whether display of 
POBs should be synchronized with the playback of the 35 
corresponding AOB files. Note that while the 
PLI_POB_SRPs in the Default_Playlist_ Information 
were described as being set by the producer of the 
music contents, these DPLLPOB_SRPs may be freely 
set by users. 40 

{82-2_83} Example Settings of the PLLPOB_SRPs 
included in a PLI 

[0475] The following describes example settings of 45 
the PLLPOB.SRPs included in a PLI. 
[0476] FIG. 83 shows one example of the settings 
of twenty PLLPOB_SRPs in a PLI. The first level in the 
drawing shows a PLI, with the inner frames showing the 
PLGI and twenty PLI_POB_SRPs. The second level so 
shows the twenty POB files POB040 to POB059. As 
shown by the arrows, the twenty PLLPOB_SRPs 
respectively specify the twenty POB files POB040 to 
POB059. 

[0477] While POB020 to POB039 are still image ss 
data that is provided by the producer of the music con- 
tents, POB040 to POB059 are still image data for per- 
sonal photos provided by the user. As examples, 



POB040 is a photo of the user's family, while POB041 is 
a photo of the user's graduation ceremony, POB042 to 
POB051 are photos of the user's pet, POB046 to 
POB051 are holiday snaps from the user's trip to 
Europe, and POB052 to POB059 are holiday snaps 
from the user's trip to the USA. To simplify the explana- 
tion, the total playback period of the AOB files specified 
by this PLI and the number of POBs specified for display 
by this PLI are the same as the 
DefaulLPIaylistJnformation. This means that the total 
playback period of TrackA to TrackE specified by this 
PLI is 52.5 minutes, and that the display period for each 
of POB040 to POB059 will be 2.625 (=52.5/20) minutes 
if each image is to be displayed for the same time during 
this playback period. 

{82-3_84} Changes in the Foreground and Back- 
ground Images as Playback Progresses 

[0478] FIG. 84 is a timing chart showing what 
images are combined when the POBs specified by the 
PLI_POB_SRPs included in the Playlistjnformation 
described above are used as background images and 
the POBs indicated by the TKI_POB_SRPs included in 
the TrackManager are used as foreground images. 
[0479] The first level in the drawing shows the same 
POBs as the second level in FIG. 83, while the second 
level shows the same POBs as the second level in 
FIGS, 75 and 76. The scale that extends horizontally 
across the top of FIG. 84 shows the playback time in 
units of one minute. The horizontal width of each POB in 
FIG. 84 therefore shows the continuous display time for 
each POB. 

[0480] By referring to the time scale in FIG. 79, it 
can be seen that during the period from the start of play- 
back to the point at 6.1 minutes, POB001 to POB003 
(the lyrics for TrackA) are displayed are successively 
displayed as the foreground image, while POB040 (a 
family photo), POB041 (a graduation photo), and 
POB042 (a pet photo) are successively displayed as the 
background image. 

[0481] In the playback period between the point 6.1 
minute after the start of playback and the point 14.9 
minutes after the start, POB004 to POB009 (the lyrics to 
TrackB and TrackC) are successively displayed as fore- 
ground images while POB042 to POB045 (pet photos) 
are successively displayed as background images. 
[0482] In the period following the point 14.9 minutes 
from the start of playback, POB010 to POB01 1 (the lyr- 
ics forTrackD) are successively displayed as foreground 
images while POB045, and POB046 to POB048 (holi- 
day snaps of European holiday) are successively dis- 
played as the background image. 
[0483] In this way, while the POBs specified by the 
DefaulLPIaylistJnformation are chosen by the record 
label that produces the music contents and so generally 
correspond to artist images and images related to the 
music contents, the POBs specified by a PLI can be 
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freely selected by the user and so can have a high per- 
sonal value. 

{82-4,85} 

[0484] In the timing chart in FIG. 84, a combined 
image composed of POB004 (the lyrics to TrackB) in the 
foreground and PO8042 (a pet photo) in the back- 
ground will be displayed starting from the point 6.1 min- 
utes after the start of playback according to the 
Playlistjnformation described above. FIG. 85 shows 
how the foreground image and background image are 
combined at this point 6.1 minutes after the start of play- 
back according to this Playlistjnformation. 

{82-5_86} 

[0485] In the same way, a combined image com- 
posed of POB010 (the lyrics to TrackD) in the fore- 
ground and POB046 (a holiday snap from Europe) in 
the background will be displayed starting from the point 
16 minutes after the start of playback according to this 
Playlistjnformation. FIG. 86 shows how the foreground 
image and background image are combined at this 
point 16 minutes after the start of playback according to 
this Playlistjnformation. The song lyrics that form part 
of these combined images are the same as in FIGS. 80 
and 81, though since the background images are differ- 
ent, the combined images in FIGS. 85 and 86 give a 
completely different impression to those in FIGS. 80 and 
81. 

[0486] As described above the PLI.POB.SRPs in 
a PLI defined by the user himself/ herself can specify 
POB files that differ from those specified by the 
Default.Playlist. Information, so that the user can have 
his/her favorite images displayed during the playback of 
his/her favorite tracks. 

{82-6.87} Example Setting of the Same POBs in the 
DPLI.POB.SRPs in the 
Default.PlaylistJnformation 

[0487] In the examples in FIGS. 78, 79, 82, and 83, 
ail of the DPI_LPOB_SRPs included in the 
Default_Playlist_lnformation specify different POB files, 
though it is possible for two or more DPLI_POB_SRPs 
in the Default_PlaylistJnformation to specify the same 
POB file. By doing so, the same POB file can be dis- 
played during the playback period of a plurality of tracks, 
making it possible to reduce the number of POB files 
that need to be provided by the title producer. This 
reduces the time and cost required to produce a title. 
[0488] FIG. 87 shows one example where the 
number of POB files is reduced by having some of the 
DPLI_POB_SRPs in the Default_Playlist_ Information 
specify the same POB file. In this drawing, both 
DPLI_POB_SRP#1 and DPI_L_POB_SRP#4 specify 
POB020, while both DPLI_POB.SRP#2 and 



DPLI_POB_SRP#5 specify POB021 . 

{82-7_88} Changes in the Foreground and Back- 
ground Images as Playback Progresses 

5 

[0489] FIG. 88 is a timing chart showing what 
images are combined when the POBs specified by the 
DPLI_POB_SRPs included in the 

DefaulLPIaylistJnformation described above are used 
10 as background images and the POBs indicated by the 
TKI_POB_SRPs included in the TrackManager are 
used as foreground images. 

[0490] As can be seen from this timing chart, 
POB020 that shows the jacket image of the packaged 

15 product is displayed a total of three times that are at the 
start of playback, 7.875 minutes after the start of play- 
back, and 15.75 minutes after the start of playback. In 
the same way, POB021 that shows the logo of the 
record label is displayed a total of three times that are 

20 2.625 minutes, 10.5 minutes, and 18.375 minutes after 
the start of playback. When the DPLI.POB.SRPs are 
set as shown in FIG. 87, the same POB is repeatedly 
displayed, so that reusable images such as the jacket 
image or record label logo can be repeatedly displayed. 

25 [0491] This completes the explanation of the TGKI, 
DPLGI, and PLGIs. 

{69-4.89} POBMG 

30 [0492] The following describes the POBManager 
(POBMGs) that is newly provided in the navigation infor- 
mation in the second embodiment. FIG. 89 shows the 
composition of the POBMG. As shown in the drawing, a 
POBMG is composed of POB Management Information 

35 (POBMGI) and POB Count Information (POBCI)#1 , #2 . 
. .#n. 

{69-4.89-1} POBMGI 

40 [0493] As shown by the broken lines in FIG. 89, the 
POB management information (POBMGI) includes 
POBMGI identification information that occupies the 0th 
and 1st bytes, a reserved field that occupies the 2nd 
and 3rd fields, a POB.Ns field that occupies the 4th and 

45 5th fields, and a reserved field that occupies the 6th and 
7th fields. 

[0494] An ID (a character set code "A6" according 
to IS0646) that identifies the POBMGI is written in the 
POBMGI identification information field. A number of 
so POBs in a range from "0" to "999" is written in the 
POB_Ns field. This completes the explanation of the 
POBMGI. 

{69-4.89-2} POBCI 

55 

[0495] The following describes the POB Count 
Information (POBCI). The POB Count Information is 
management information that is provided separately for 
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each POB. The bit construction of the POB Count Infor- 
mation is as shown by the broken lines in FIG. 89. That 
is, the POB Count Information includes a POB_RCN 
field that occupies the region from bit number bO to bit 
number b9, a reserved field that occupies the regions 5 
from bit number b10 to b13, and a data existence field 
that occupies the region from bit number b14 to bit 
number b1 5. 

{69-4.89-3} POB.RCN 10 

[0496] The "POBJRCN" field shows whether the 
display of a POB corresponding to a POBCI is specified 
by the DPLGI, a PLGI, or a TKGI. When the corre- 
sponding POB is specified, the number of specifica- is 
tions, that is, the number of TKIs specifying the POB for 
display, is written as a number in the range "1" to "999". 
[0497] As in the first embodiment, TKIs can be 
deleted so that the settings in the 
Default_Playlist_lnformation and the 20 

Playlistjnformation can be freely changed by users. 
When one or more TKIs that specify a particular POB 
are deleted, the POB reference count for that POB has 
to be decremented in accordance with the number of 
specifying TKIs that have been deleted. Also, when the 25 
Default_PlaylistJnformation or a PLI is deleted, the 
POB_RCN has to be decremented by the number of 
specifying TKIs that have been deleted. 
[0498] When a POB is not specified by the DPLGI, 
a PLGI, or the TKGI, the POB_reference_count is set at 30 
"0". As a POB whose POB_reference_count is "0" is not 
referred to by a TKI or a playlist, on deleting a TKI or 
playlist, a playback apparatus can detect POBs whose 
reference_count_number becomes zero and delete the 
POB files storing such POBs to reduce the amount of 35 
still image data recorded in the flash memory card. 
[0499] When certain POBs have a strong relation- 
ship with certain tracks and such POBs will be meaning- 
less if not displayed during the playback of the related 
tracks, such POBs can be deleted when their 40 
reference_count_number becomes zero to avoid waste- 
ful usage of the storage capacity of the flash memory 
card. This could apply to the case of POBs showing 
song lyrics for tracks recorded in the flash memory card. 
[0500] Apart from when one or more TKIs are 45 
deleted, when a POB specified by a DPLI_POB_SRP, a 
PLI_POB_SRP, and/or a TKI_POB_SRP is deleted by 
an editing operation, the reference_count_number may 
be decremented in the same way. 

50 

{69-4_89-4} Data Existence 

[0501] The data existence field that occupies bit 
number b14 and bit number b15 is set to indicate 
whether a POB that corresponds to the present POB 55 
number exists. The binary value "01" is set in this field 
when a corresponding POB exists, while the value "00" 
is set when there is no such POB. Here, data is said to 



"exist" when data with intrinsic value is present. 
[0502] When this field indicates that a POB exists 
and the deletion of a TKI or PLI has resulted in the 
POB_reference_count reaching "0", a playback appara- 
tus will judge that the POB corresponding to the "0" 
POB_reference_count should be kept and so will not 
delete the POB. 

[0503] If a POB has intrinsic value regardless of 
whether it is referred to by a TKI or a PLI, the data exist- 
ence field corresponding to this POB can be set at "1". 
By setting the data existence field corresponding to 
POBs that are only of value if they are referred to by a 
TKI or a playlist at "0", it becomes possible to selectively 
keep only POBs with intrinsic value on the flash memory 
card. POBs that are only meaningful when displayed 
together with the playback of a track (i.e., POBs that 
have no intrinsic value) can be deleted when the corre- 
sponding track is deleted, enabling the storage capacity 
of the flash memory card to be used efficiently 
[0504] This completes the explanation of the POB- 
Manager (POBMG). 

{69-5} Updating that Accompanies the Editing of 
TKIs 

[0505] The following describes how the 
TKI_POB_SRPs and the DPLI_POB_SRPs are 
updated in the following five cases. The first four cases 
are the same as in the first embodiment, so that in the 
first case (easel), a track is deleted. In the second case 
(case2) a track is deleted and a new track is recorded. 
In the third case (case3) two out of a plurality of tracks 
are selected and combined into a single track. In the 
fourth case (case4), one track is divided to produce two 
tracks. In the fifth case (case5), the playback order of 
tracks is changed. 

[0506] In easel where a track is deleted, each TKI 
corresponding to the track is set at "Unused" and the 
TKI_POB_SRPs in each TKI are deleted. At the same 
time, the POB_reference_count in the POBManager of 
the POBs specified by these TKLPOB_SRPs are dec- 
remented. POBs that are specified by PLI_POB_SRPs 
and/or DPLI_POB_SRPs in the DPLGI or a PLGI are 
unaffected by this deletion. 

[0507] When the DPL_TK_SRPs are changed so 
as to specify the tracks in a different order (case5), the 
playback order of tracks will change, so that the display 
order of the POBs specified by the TKI_POB_SRPs will 
also change. 

[0508] In case3, it is preferable for the 
TKLPOB_SRPs in the TKIs to also be combined. This 
is because only the TKI_POB_SRPs in a first TKI are 
valid for a track composed of a plurality of TKIs. When a 
track combining operation is performed, the POBs spec- 
ified by the TKI_POB_SRPs of the latter TKI will need to 
be specified by TKI_POB_SRPs in the former TKI. 
[0509] When a track is divided (case4), it is neces- 
sary to change the TKI_BLK_ATR of the track and to 
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divide the TKTMSRT and BIT as described in the first 
embodiment. In addition, the TKI_POB_SRPs specified 
in the TKGI also need to be divided into two groups that 
are respectively assigned to the former TKI and to the 
extra TKI that is newly produced by the division. 

{69-6} Actual Example of How the TKI_POB_SRPs 
and DPLI_POB_SRPs May Be Used 

[0510] As described above, the data constructions 
of the TrackManager and PlaylistManager allow the 
user to freely change the relationship between AOB 
files and POBs by changing the settings of the 
TKI_POB_SRPs, DPLI_POB_SRPs, and 

Pl_LPOB_SRPs. This means that a producer of music 
contents can provide music contents with differing 
amounts of still image data to consumers, such as 
tracks with lyrics, tracks with no lyrics, and tracks with 
lyrics and background images. Of course, the producer 
may charge different amounts for these different types 
of contents. 

[051 1 ] When a consumer wishes to buy tracks with- 
out the lyrics, the producer may produce an SD_Audio 
directory that includes the eight AOBs shown in the first 
embodiment and a TrackManager where the 
TKI_POB_SRPs in TKI#1 to TKI#8 specify POB020 to 
POB039 as shown in FIG. 78. The producer then com- 
presses this directory, encrypts it, and transmits it to the 
consumer's personal computer. Note that the con- 
sumer's personal computer can instead download 
tracks (AOBs) and still images (POBs) corresponding to 
the tracks from a server computer operated by the 
record label and generate the SD-Audio directory 
shown in FIGS. 70A and 70B on the flash memory card 
31. 

[0512] When the consumer wishes to buy tracks 
with the lyrics, the producer may produce an SD_Audio 
directory that includes the eight AOBs shown in the first 
embodiment and a TrackManager where the 
TKI_POB_SRPs in TKI#1 to TKI#8 specify POB001 to 
POB019 shown in FIGS. 75 and 76 corresponding to 
the lyrics. The producer then compresses this directory, 
encrypts it, and transmits it to the consumer's personal 
computer. 

[0513] When the consumer wishes to buy tracks 
with both the lyrics and the background images, the pro- 
ducer may produce an SD_Audio directory that includes 
the eight AOBs shown in the first embodiment, a Track- 
Manager where the TKI_POB_SRPs in TKI#1 to TKI#8 
specify POB001 to POB019 shown in FIGS. 75 and 76 
corresponding to the lyrics, and a Playlist Manager 
where the DPLLPOB_SRPs specify POB020 to 
POB039 shown in FIG. 78. The producer then com- 
presses this directory, encrypts it, and trOansmits it to 
the consumer's personal computer. Since still image 
data can be freely associated with audio data by setting 
the TKI_POB_SRPs, DPLI_POB_SRPs, and 
PLLPOB_SRPs in the present embodiment, music 



contents can be easily produced with different prices in 
accordance with the amount of associated still image 
data. 

5 {90-1_91} Playback Apparatus for the Second 
Embodiment 

[0514] The following describes a playback appara- 
tus for the second embodiment. This playback appara- 
w tus differs from the playback apparatus described in the 
first embodiment in that while the playback apparatus in 
the first embodiment is portable, the playback apparatus 
in the second embodiment is designed for installation as 
a car stereo. 

15 [0515] FIG. 90 shows how the playback apparatus 
of the second embodiment is used, while FIG. 91 shows 
the external appearance of just the playback apparatus. 
[0516] The playback apparatus of this second 
embodiment differs from the playback apparatus of the 

20 first embodiment in that it is installed in an automobile 
as shown in FIG. 90, in that it includes a large. LCD 
panel 5, and in that it is connected to car speakers. Due 
to the provision of the large LCD panel 5, the playback 
apparatus of this second embodiment is well suited to 

25 the display of the various types of still image data men- 
tioned above. 

[0517] A second difference with the playback appa- 
ratus of the first embodiment is that the playback appa- 
ratus of the second embodiment has a descrambler 7 

30 that is capable of decrypting encrypted POBs as well as 
encrypted audio data. When a POB has been encrypted 
and is stored as a POB file with a "POBXXX.SPI" 
filename, a FileKey stored in a Key Entry in the 
encrypted key storing file "POBSP1.KEY" is set in the 

35 descrambler 7 which then decrypts the file 
"POBXXX.SP1\ 

[0518] A third difference with the playback appara- 
tus of the first embodiment is that the playback appara- 
tus of the second embodiment stores a program 
40 including the processing required to display POBs as 
foreground or background images. The CPU 10 in this 
playback apparatus executes this program to display 
images. 

45 {90-2_92_93_94} 

[0519] The following describes the composition of 
the playback apparatus in this second embodiment. The 
composition of the playback apparatus shown in FIG. 92 
so differs from the composition of the playback apparatus 
of the first embodiment in that it includes a plurality of 
VRAMs 61. 

[0520] The plurality of VRAMs 61 respectively cor- 
respond to the single graphics planes (layers). The 
55 VRAM for a graphics plan has transparency a set in the 
range 0 to 100% for each pixel. The image that is to be 
displayed on the first LCD panel 5 is calculated accord- 
ing to the equation given below. FIG. 93A shows how 
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the still images stored in the plurality of VRAMs 61 are 
combined. 

Equation 

5 

[0521] 

Pixel Value of Each Pixel = Pixel Value in Graphics 
Plane 0*(1-oc) + Pixel Value in Graphics Plane 1*a 

10 

[0522] The transparency a is set at 0% for the parts 
of the foreground image corresponding to the charac- 
ters showing the lyrics. As a result, parts of the back- 
ground image that positionally correspond to the 
character strings showing the lyrics are completely hid- 15 
den. Conversely, the transparency a is set at 100% for 
the parts of the foreground image corresponding to 
plain background of the lyrics. This means that the com- 
bined image has the character strings showing the lyrics 
in graphics plane 0 displayed on top of the background 20 
image in graphics plane 1. 

[0523] By setting the transparency in this way, it is 
possible to produce a combined image where a lyrics 
sheet is laid on top of a background image, as shown in 
FIGS. 80 and 81. Note that a combined image can be 25 
produced in other ways a side from that shown in 
FIG.93A. As one example, the lyrics may be arranged 
into the lower part of the screen, with the background 
image being shown in the upper part, as shown in FIG. 
93B. 30 

{94-1} Flowchart of the Foreground Image Display 
Procedure 

[0524] FIG. 94 is a flowchart showing the fore- 35 
ground image display procedure. When playback starts 
according to TKI#z specified by the 
Default_Playlist_lnformation, in step S402 the CPU 10 
judges whether the TKI_POB_SRPs included in the 
TKGIs in TKI#z specify any POBs. When the 40 
TKI_POB_SRPs specify one or more POB files, the 
processing advances to step S403 where the CPU 10 
counts the number of POB files that are specified by the 
TKLPOB.SRPs included in the TKGI. In step S404, the 
CPU 10 calculates the display time "POBJime" show- 45 
ing the display period to be used for each POB file. After 
this, in step S405 refers to the TKI_POB_ATR in the 
TKGI and determines the display mode to be used for 
displaying the POB files. When the TKI_POB_ATR 
shows sequential mode, the processing advances from so 
step S405 to step S406, where the variable i is initial- 
ized, and to step S407, where the POB file specified by 
the i th TKI_POB_SRP is displayed for the display time 
POBJime. 

[0525] At this point, when the extension of the POB 55 
file specified by the TKI_POB_SRP j S "JPG", the POB is 
displayed as it is. Conversely, when the extension of the 
POB file specified by the TKI_POB_SRP is n SPV, the 



POB file will be in an encrypted state, so that the CPU 
10 reads the FileKey corresponding to the POB file from 
the protected area, decrypts the POB file using the 
encryption key, and displays the POB. 
[0526] After this, in step S408 the CPU 10 judges 
whether the variable i has reached the value given in 
POB_Ns. If not, the processing proceeds to step S409, 
where the variable i is incremented, and then returns to 
step S407. The processing in steps S406 to S409 is 
hereafter repeated until the variable i reaches the value 
given in POB_Ns. As a result, the POBs specified by the 
TKI_POB_SRPs in the TKGI are sequentially displayed. 
When the variable i reaches the value given in POB_Ns, 
the processing in this flowchart ends. 
[0527] When the TKI_POB_ATR shows random 
mode, the processing advances from step S405 to step 

5410, where the variable i is initialized, and to step 

541 1 , where the CPU 10 generates a random number r 
in a range from 1 to POB_Ns. In step S412 the POB file 
specified by the r lh TKI_POB_SRP corresponding to the 
random number r is displayed for the display time 
POBJime determined in step S404. 

[0528] After this, in step S413 the CPU 10 judges 
whether the variable i has reached the value given in 
POB_Ns. If not, the processing proceeds to step S414, 
where the variable i is incremented, and then returns to 
step S41 1 . In step S41 1 , the CPU 1 0 generates another 
random number r in a range from 1 to POB_Ns, and the 
processing proceeds again to step S412, where the 
CPU 10 reads the POB file specified by the r th 
TKI_POB_SRP corresponding to the random number r 
and displays it for the display time POBJime deter- 
mined in step S404. 

[0529] As described above, when the extension of 
the POB file specified by the TKI_POB_SRP is "JPG", 
the POB is displayed as It is. Conversely, when the 
extension of the POB file specified by the 
TKI_POB_SRP is "SP1", the POB file will be in an 
encrypted state, so that the CPU 10 reads the FileKey 
corresponding to the POB file from the protected area, 
decrypts the POB file using the encryption key, and dis- 
plays the POB. 

[0530] The processing in steps S411 to S414 is 
hereafter repeated until the variable i reaches the value 
given in POB_Ns. As a result POBs specified by the 
TKLPOB_SRPs in the TKGI are displayed one after 
another in a random order. When the variable i reaches 
the value given in POB_Ns, the processing in this flow- 
chart ends. 

[0531] When the TKI_POB_ATR shows shuffle 
mode, the processing advances from step S405 to step 

5415, where the variable i is initialized, and to step 

541 6, where the CPU 10 generates a random number r 
in a range from 1 to POB_Ns. 

[0532] In step S418, the CPU 10 checks whether 
the newly generated random number r matches one of 
the used POB numbers that has been previously stored. 
If so, the processing returns to step S41 6 where the ran- 
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dom number r is regenerated. If not, the processing 
advances from step S418 to S419 where the POB file 
specified by the r th TKI_POB_SRP corresponding to the 
random number r is displayed for the display time 
POBJime determined in step S404. After this, in step 5 
S417theCPU 10 stores the random number r as a used 
POB number, 

[0533] As in random mode, when the extension of 
the POB file specified by the TKI_POB_SRP is "JPG", 
the POB is displayed as it is. Conversely, when the w 
extension of the POB file specified by the 
TKI_POB_SRP is "SP1", the POB file will be in an 
encrypted state, so that the CPU 10 reads the FileKey 
corresponding to the POB file from the protected area, 
decrypts the POB file using the encryption key, and dis- 15 
plays the POB. When this display ends, in step S420 the 
CPU 10 judges whether the variable i has reached the 
value given in POB_Ns. If not, the processing proceeds 
to step S421, where the variable i is incremented, and 
then returns to step S416. The processing in steps 20 
S416 to S421 is hereafter repeated until the variable i 
reaches the value given in POB_Ns. When the variable 
i reaches the value given in POB_Ns, the processing in 
this flowchart ends. 

25 

{95-1} Flowchart of the Background Image Display 
Procedure 

[0534] The procedure for displaying a foreground 
image is as described above and the following 30 
describes the procedure for displaying a background 
image. FIG. 95 is a flowchart for the background image 
display procedure. This flowchart contains fundamen- 
tally the same processing as the flowchart in FIG. 94, 
with the processing being performed acoording to the 35 
DPLLPOB_SRPs and DPLI_POB_ATR in the DPLGI 
instead of the TKI_POB_SRPs and TKI_POB_ATRs in 
the TKGI. 

[0535] When the Default_Playlist_ Information is 
selected, the CPU 10 performs the processing in steps 40 
S502 to S505. As in steps S402 to S405, the CPU 10 
judges whether the DPLI_POB_SRPs included in the 
DPLGI specify any POBs. When one or more POB files 
are specified, the CPU 10 counts the number of POB 
files that are specified, calculates the display time 45 
POBJime showing the display period to be used for 
each POB file, and then determines the display mode to 
be used for displaying the POB files. 
[0536] When the DPLI_POB_ATR shows sequen- 
tial mode, the CPU 1 0 performs step S506 to step S509. 50 
As in step S406 to S409, POB files are sequentially dis- 
played in order in accordance with a DPLI_POB_SRP, 
out of the DPLLPOB_SRPs included in the DPLGI, 
indicated by the variable i. 

[0537] When the DPLI_POB_ATR shows random 55 
mode, the CPU 10 performs step S510 to step S514. As 
in step S410 to S414, POB files are displayed in a ran- 
dom order in accordance with a DPLI_POB_SRP, out of 



the DPLI_POB_SRPs included in the DPLGI, indicated 
by the random number r. 

[0538] When the DPLLPOB_ATR shows shuffle 
mode, the CPU 1 0 performs step S51 5 to step S521 . As 
in step S415 to S421, POB files are displayed in a ran- 
dom order with no repetition in accordance with a 
DPLI_POB_SRP, out of the DPLI_POB_SRPs included 
in the DPLGI, indicated by the random number r. 

{96-1} Flowchart of the Background Image Display 
Procedure 

[0539] This completes the background image dis- 
play procedure that is performed based on the 
DPLI_POB_SRPs in DPLGI. The following describes 
the background image display procedure that is per- 
formed based on the PLI_POB_SRPs in a PLGI. FIG. 
96 is a flowchart showing the background image display 
procedure based on the PLI_POB_SRPs. With the 
exception of the processes based on DPLLPOB.SRPs 
being performed based on PLI_POB_SRPs, this flow- 
chart is exactly the same as the flowchart in FIG. 95, so 
that the processes have been given the same reference 
numerals. No explanation of FIG. 96 will be given. 

{94-2_95-2_97A,B,C} Example Display Screens on 
the LCD Panel 5 

[0540] FIGS. 97A to 97C show what kind of com- 
bined images are displayed on the LCD panel 5 when a 
foreground image specified by a TKLPOB_SRP and a 
background image specified by the DPLGI are dis- 
played according to the display procedures shown in the 
flowcharts in FIGS. 94 and 95. 
[0541] In the example in FIG. 97A, assume that the 
user indicates the DefaulLPIaylistJnformation and that 
the display of POBs begins in accordance with the play- 
back order given in this playlist. The foreground image 
display procedure shown in FIG. 94 and the background 
image display procedure shown in FIG. 95 are per- 
formed and the POBs specified for display by the 
TKI_POB_SRPs in the TKGI and the POBs specified for 
display by the DPLI_POB_SRPs in the DPLGI are dis- 
played one after another. At a point six minutes after the 
start of playback, images are combined as shown in 
FIG. 80 and the combined image shown in FIG. 97B is 
displayed on the LCD panel 5. 
[0542] At a point sixteen minutes after the start of 
playback, images are combined as shown in FIG. 81 
and the combined image shown in FIG. 97C is dis- 
played on the LCD panel 5. 

{94-2_96-1_98A l B,C} Example Display Screens on 
the LCD Panel 5 

[0543] FIGS. 98A to 98C show what kind of com- 
bined images are displayed on the LCD panel 5 when a 
foreground image specified by a TKI_POB_SRP and a 
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background image specified by a PLI_POB_SRP are 
displayed according to the display procedures shown in 
the flowcharts in FIGS. 94 and 96. 
[0544] In the example in FIG. 97A, assume that the 
user indicates a PLI and that the display of POBs begins 5 
in accordance with the playback order given in this play- 
list. The foreground image display procedure shown in 
FIG. 94 and the background image display procedure 
shown in FIG. 96 are performed and the POBs specified 
for display by the TKI_POB_SRPs in the TKGI and the w 
POBs specified for display by the PLI_POB_SRPs in 
the PLGI are displayed one after another. At a point six 
minutes after the start of playback, images are com- 
bined as shown in FIG. 85 and the combined image 
shown in FIG. 98B is displayed on the LCD panel 5. At 15 
a point sixteen minutes after the start of playback, 
images are combined as shown in FIG. 86 and the com- 
bined image shown in FIG. 98C is displayed on the LCD 
panel 5. 

20 

{99_1} Recording Apparatus of the Second Embod- 
iment 

[0545] The following describes a recording appara- 
tus of this second embodiment. This recording appara- 25 
tus differs from that of the first embodiment in that it is 
capable of recording a plurality of POBs onto a flash 
memory card, of setting values in the TKI_POB_SRPs, 
DPLI_POB_SRPs, and PLLPOB_SRPs, and setting 
values in the TKLPOB.ATR, DPLI_POB_ATR, and 30 
PLI_POB_ATR. 

[0546] To perform these processes, the CPU 10 in 
the recording apparatus of this second embodiment 
executes the procedure shown in FIG. 99. The following 
describes the recording procedure executed by the 35 
recording apparatus of this second embodiment with 
reference to the flowchart shown in FIG. 99. 
[0547] In step S601 , the CPU 1 0 initializes the vari- 
ous variables used in this procedure. These are the var- 
iables #x, #y, #z, #u, #vy, and #w. Of these, the variable 40 
#x is used to specify which POB is presently being proc- 
essed, the variable #y is used to specify which track 
sequence (PLI) is presently being processed, and the 
variable #z is used to specify which track (TKI) is pres- 
ently being processed. The variable #u specifies which 45 
of the DPLLPOB_SRPs is being processed, while the 
variable #vy which of the PLI_POB_SRPs in the PLI 
(PLI#y) specified by the variable #y is being processed. 
The variable #w specifies which TKI_POB_SRPs in the 
TKI (TKI#z) specified by the variable #z is presently 50 
being processed. 

[0548] After initializing these variables, the CPU 10 
advances to step S602 where it displays POB#x. This 
allows the user to visually confirm the photo, illustration, 
or lyric sheet in this POB. In step S603, the CPU 10 55 
asks the user to indicate whether the still image data in 
POB#x is to be displayed throughout the entire track 
sequence or just during the playback period of a specific 



track, and then receives a user selection. 
[0549] When the user judges that POB#x should be 
assigned to a track sequence, in step S604 the CPU 10 
waits for the user to indicate the track sequence for 
which POB#x should be displayed. When the user 
inputs his/her selection, the processing proceeds to 
step S605 when the CPU 10 judges whether the indi- 
cated track sequence #y is the DPLI or a PLI. When the 
track sequence #y is the DPLI, the processing proceeds 
to S606 where POB#x is set in the DPLI_POB_SRP#u, 
and then to S607 where the DPLI_POB_ATR#u of the 
DPLI is set based on this POB#x. 
[0550] Once a DPLLPOB_SRP and the 
DPLI_POB_ATR have been set in this way, the CPU 10 
increments the variable #u (#u->#u+1) in step S608 and 
the variable #x (#x-»#x+1) in step S609. 
[0551] When a PLI is selected in step S605, the 
processing proceeds to step S610 where POB#x is set 
in the PLI_POB_SRP#vy in PLI#y, and to step S611 
where the PLI_POB_ATR#vy for this PLI is set based on 
POB#x. After this, in step S612 the CPU 10 increments 
the variable #vy (#vy->#vy+1), before advancing to step 
S609 to increment the variable #x (#x->#x+1). 
[0552] When, in step S603, the user judges that 
POB#x should be assigned to a specific track, the 
processing advances to step S613 where the CPU 10 
receives a user indication of this specific track. Next, in 
step S614, the CPU 10 sets POB#x in a 
TKI_POB_SRP#w set for the TKI#z of the indicated 
track (track#z). 

[0553] The processing then proceeds to step S615 
where the CPU 10 sets the TKI_POB_ATR#w of TKI#z 
based on the POB#x. to step S616 where the CPU 10 
increments the variable #w (#w->#w+1) and to step 
S617 where the CPU 10 whether the variable #x has 
reached the final number #n in a POB. If not, the 
processing proceeds to step S609 where the CPU 10 
increments the variable #x. If the variable #x has 
reached the final number #n in a POB, the processing 
proceeds to step S618 where POB#1 to POB#n, the 
TKMG including the TKIs, and the PLMG including the 
DPLI and PLIs are recorded on the semiconductor 
memory card to end the processing. 
[0554] In these embodiments, it is possible to have 
the same still image data, such as an artist photo or a 
record label logo, displayed as a background image dur- 
ing the playback of a plurality of tracks. This is achieved 
by merely specifying the still image data in 
DPLI_POB_SRPs or PLI_POB_SRPs that correspond 
to such tracks in the Defaulty_Playlist_ Information or in 
a PLI. 

[0555] Still image data, such as a lyrics sheet, that 
is to be displayed with a background image only during 
the playback of a particular track can be specified by a 
TKI_POB_SRP in the TKI of the track. 
[0556] The above explanation focuses on what is 
presently believed to be the ideal system for realizing 
the concept of the present invention, though it should be 
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obvious that several modifications can be made within 
the scope of the invention. Three examples of such are 
given as (a), (b) and (c) below. 

(a) The procedures explained using the flowcharts 5 
in FIGS. 94, 95, 96, and 99 can be achieved by pro- 
grams that may be distributed and sold having been 
recorded onto a recording medium. 

(b) The present embodiments describe the case w 
where the presentation data and navigation data 

are used for music contents, although it should be 
obvious that such data can be used for an audio- 
book that is a recording of an actor or announcer 
reading from a book. In such case, still image data 15 
that shows text from the book can be ideally speci- 
fied by the TKI_POB_SRPs as the foreground 
images while the illustrations from the book are 
specified by the DPLI_POB_SRPs or 
PLI_POB_SRPs. 20 

(c) In this second embodiment, the POBs specified 
by DPLI_POB_SRPs and PI_LPOB_SRPs are 
used as background images while the POBs speci- 
fied by TKI_POB_SRPs are used as foreground 25 
images, though the opposite setup may be used. 
Alternatively, when different POBs are simultane- 
ously specified by a DPLI_POB_SRP or 
PLI_POB_SRP and a TKI_POB_SRP, only one of 
such POBs may be displayed. As another alterna- 30 
tive, no distinction into "background image" and 
•foreground image" need be used. As one example, 

a POB specified by a DPI_LPOB_SRP or 
PLI_POB_SRP may be displayed first, and a POB 
specified by a TKI_POB_SRP may be displayed 35 
next. 

THIRD EMBODIMENT 

[0557] While the second embodiment describes the 40 
case where each POB is displayed for an equal period 
during the valid period of a TKI and a PLI, this third 
embodiment describes the case where a phrase timing 
table and a highlight coordinate table are also stored on 
the flash memory card 31 so that the display of lyrics 45 
can be properly synchronized to the playback of a song. 
[0558] The phrase timing table associates the 
TKI_POB_SRPs specifying the POBs showing each 
section of the lyrics with information showing at what 
time the corresponding phrase begins and ends in a so 
song. FIG. 100A shows one example of the phrase tim- 
ing table. In this example, "phrase timing" refers to the 
period during which a phrase given in the lyrics of a 
track is being sung as part of the playback of the AOB. 
This period is expressed to an accuracy of milliseconds. 55 
In addition to updating the playback time code as 
described In the first embodiment, a playback apparatus 
monitors the phrase timing given in this table that corre- 



sponds to the current value of the playback time code. 
By monitoring the phrase timing in this way, the play- 
back apparatus can know which POB stores the lyrics 
for the AOB, AOB_ ELEMENT, and AOB_ FRAME cur- 
rently being played back. Using a table that gives the 
phrase timing of a POB in milliseconds in this way 
allows the playback apparatus to synchronize the play- 
back of AOBs and the display of lyrics to millisecond 
accuracy. 

[0559] When the user indicates a desired playback 
start time using the jog dial as described in the first 
embodiment, the playback apparatus can find which 
AO B_ FRAME in which AOB_ELEMENT in which AOB 
corresponds to the indicated playback start time using 
Equations 1 to 3 given in the first embodiment. The play- 
back apparatus also judges which phrase timing 
includes the indicated playback start time and has the 
POB corresponding to this phrase timing displayed. 
This means that when the user has playback start from 
a desired position indicated using the jog dial, the 
appropriate POB for this desired position can also be 
displayed. Note that while the present case states that 
times are given in the phrase timing table, the AOB 
number, AOB_ELEMENT number and AOB_FRAME 
number of the AOB, AOB_ELEMENT, and 
AO B_ FRAME to which a phrase should be synchro- 
nized may be given in the phrase timing table instead. 
[0560] On the other hand, the highlight coordinate 
table associates the display coordinates of characters 
used in the lyrics and the timing at which the 
AOB_ELEMENT and AOB_FRAMEs corresponding to 
these characters will be played back. FIG. 100B shows 
one example of the highlight coordinate table. Preparing 
this kind of highlight coordinate table enables a play- 
back apparatus to display the characters corresponding 
to the lyrics, out of the lyrics displayed according to the 
phrase timing, in the AOB_ELEMENT and 
AOB_ FRAME currently being played back in a different 
color, 

[0561] As one example, when the lyrics include the 
phrase "Hey hey boy don't take it slow", the highlight 
coordinate table will include display coordinates for the 
characters "H", "e", "y", "h", "e", V, ... that are associ- 
ated with the playback period of the AOB_ELEMENT 
and AOB_FRAME corresponding to these characters. 
When playing back an AOB, the playback apparatus 
changes the color of the position shown by the display 
coordinates of the characters given in the highlight coor- 
dinate table. 

[0562] The playback apparatus can therefore dis- 
play the lyrics in a manner that allows the user to 
instantly recognize what part of the AOB is currently 
being played back. This means that music recorded on 
a flash memory card can be played back with high- 
lighted lyrics in the same way as conventional karaoke 
tracks. 

[0563] In this third embodiment, the phrase timing 
table and highlight coordinate table are provided to ena- 
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ble precise synchronization between audio playback 
and the displayed lyrics, in the same way as conven- 
tional karaoke tracks. 

[0564] Although the present invention has been 
fully described with reference to the accompanying 5 
drawings, it is to be noted that various changes and 
modifications will be apparent to those skilled in the art. 
Therefore, unless such changes and modifications 
depart from scope of the present invention, they should 
be construed as being included therein. w 

Claims 

1. A semiconductor memory card, storing: 

15 

an audio sequence including a plurality of 
audio objects; 

a plurality of still image objects; 
at least one piece of playback route information 
showing an order in which audio objects, out of 20 
the plurality of audio objects in the audio 
sequence, are to be played back; 
at least one piece of first pointer information, 
each of which corresponds to a piece of play- 
back route information and specifies at least 25 
one still image object that should be displayed 
when the audio objects in the order indicated 
by the corresponding piece of playback route 
information are played back; and 
at least one piece of second pointer informa- 30 
tion, each of which corresponds to an audio 
object in the audio sequence and specifies at 
least one still image object that should be dis- 
played only during playback of the correspond- 
ing audio object. 35 

2. A semiconductor memory card according to Claim 
1, 

wherein at least one audio object is music 
data, 40 

the plurality of still image objects includes at 
least one still image object showing lyrics for a 
song represented by music data in an audio 
object, and 45 
at least one piece of second pointer information 
specifies each still image object showing lyrics 
for a song represented by music data in the 
audio object corresponding to the piece of sec- 
ond pointer information. so 

3. A semiconductor memory card according to Claim 
1, further storing 

a plurality of symbolic counters, each of which 55 
corresponds to a still image object and shows 
whether the still image object is specified by 
any of the at least one piece of first pointer 



information and the at least one piece of sec- 
ond pointer information and, if so, how many 
pieces of first pointer information and second 
pointer information specify the still image 
object. 

4. A semiconductor memory card according to Claim 
1, 

wherein the plurality of still image objects 
includes at least one still image object that has 
been encrypted, and 

the semiconductor memory card further stores: 
management information including identifica- 
tion information for each still image object, 
additional information showing whether each 
still image object has been encrypted, and a 
storage position of each still image object; and 
at least one decryption key for use when 
decrypting the at least one encrypted still 
image object, the at least one decryption key 
being accessible to a device connected to the 
semiconductor memory card only if the device 
has been found to be authentic, 
the pieces of first pointer information and sec- 
ond pointer information specifying still image 
objects using the identification information 
given in the management information. 

5. A semiconductor memory card according to Claim 
4, including: 

a protected area that stores the at least one 
decryption key and is accessible to a device 
connected to the semiconductor memory card 
only if the device has been found to be authen- 
tic; and 

an unprotected area that is accessible to any 
device connected to the semiconductor mem- 
ory card, 

the audio sequence, the plurality of still image 
objects, each piece of playback route informa- 
tion, each piece of first pointer information, 
each piece of second pointer information, and 
the management information being stored in 
the unprotected area, and 
the at least one encrypted still image object 
having been encrypted using the at least one 
decryption key stored in the protected area. 

6. A semiconductor memory card according to Claim 
5, 

wherein at least two still image objects, out 
of the plurality of still image objects, have been 
encrypted, 

at least two decryption keys are stored in a pre- 
determined order in the protected area as a 
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decryption key sequence, and 
the identification information for each 
encrypted still image object includes a key 
number showing a position in the decryption 
key sequence of the decryption key corre- 5 
sponding to the encrypted still image object. 

7. A playback apparatus for a semiconductor memory 
card, 

10 

the semiconductor memory card storing (1) an 
audio sequence including a plurality of audio 
objects, (2) a plurality of still image objects, (3) 
first pointer information specifying at least one 
still image object that should be displayed 15 
when the plurality of audio objects in the audio 
sequence are played back, and (4) at least one 
piece of second pointer information, each of 
which specifies at least one still image object 
that should be displayed only when a particular 20 
audio object in the audio sequence is played 
back, 

the playback apparatus comprising: 
playback means for playing back audio objects 
in the audio sequence one at a time in order; 25 
display means for displaying the at least one 
still image object specified by the first pointer 
information throughout playback of the audio 
objects in the audio sequence; and 
control means for having the display means 30 
display the at least one still image object spec- 
ified by a piece of second pointer information 
throughout playback of a particular audio 
object corresponding to the piece of second 
pointer information. 35 

8. A playback apparatus according to Claim 7, 

wherein the control means has the display 
means display a combined image produced by 
combining the at least one still image object speci- 40 
fied by the piece of second pointer information with 
the at least one still image object specified by the 
first pointer information. 

9. A recording apparatus for a semiconductor memory 45 
card that stores a plurality of still image objects and 

an audio sequence including a plurality of audio 
objects, 

the recording apparatus comprising: so 
assigning means for assigning to the audio 
sequence at least one still image object that is 
to be displayed throughout playback of the plu- 
rality of audio objects, and assigning at least 
one still image object that is to be displayed 55 
throughout playback of a particular audio 
object to the particular audio object; and 
recording means for recording 



(1) first pointer information showing the at 
least one still image object assigned to the 
audio sequence, and 

(2) second pointer information showing the 
at least one still image object assigned to 
the particular audio object 

onto the semiconductor memory card. 

10. A computer-readable storage medium storing a 
program that has a computer execute a playback 
procedure for a semiconductor memory card, the 
semiconductor memory card storing (1) an audio 
sequence including a plurality of audio objects, (2) 
a plurality of still image objects, (3) first pointer 
information specifying at least one still image object 
that should be displayed when the plurality of audio 
objects in the audio sequence are played back, and 
(4) at least one piece of second pointer information, 
each of which specifies at least one still image 
object that should be displayed only when a partic- 
ular audio object in the audio sequence is played 
back, 

the program comprising: 
a playback step for playing back audio objects 
in the audio sequence one at a time in order; 
a display step for displaying the at least one still 
image object specified by the first pointer infor- 
mation throughout playback of the audio 
objects in the audio sequence; and 
a control step for having the display step dis- 
play the at least one still image object specified 
by a piece of second pointer information 
throughout playback of a particular audio 
object corresponding to the piece of second 
pointer information. 

11. A computer-readable storage medium according to 
Claim 10, 

wherein the control step has the display step 
display a combined image produced by combining 
the at least one still image object specified by the 
piece of second pointer information with the at least 
one still image object specified by the first pointer 
information. 

12. A computer-readable storage medium storing a 
program that has a computer execute a recording 
procedure for a semiconductor memory card that 
stores a plurality of still image objects and an audio 
sequence including a plurality of audio objects, 

the program comprising: 
an assigning step for assigning to the audio 
sequence at least one still image object that is 
to be displayed throughout playback of the plu- 
rality of audio objects, and assigning at least 
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one still image object that is to be displayed 
throughout playback of a particular audio 
object to the particular audio object; and 
a recording step for recording 



rality of audio objects, and assigning at least 
one still image object that is to be displayed 
throughout playback of a particular audio 
object to the particular audio object; and 



5 



a recording step for recording 



(1) first pointer information showing the at 
least one still image object assigned to the 
audio sequence, and 



(1) first pointer information showing the at 
least one still image object assigned to the 
audio sequence, and 



(2) second pointer information showing the 



at least one still image object assigned to w 



(2) second pointer information showing the 
at least one still image object assigned to 
the particular audio object 



the particular audio object 



onto the semiconductor memory card. 



onto the semiconductor memory card. 



13. A playback method for playing back data from a 15 
semiconductor memory card, the semiconductor 
memory card storing (1) an audio sequence includ- 
ing a plurality of audio objects, (2) a plurality of still 
image objects, (3) first pointer information specify- 
ing at least one still image object that should be dis- 20 
played when the plurality of audio objects in the 
audio sequence are played back, and (4) at least 
one piece of second pointer information, each of 
which specifies at least one still image object that 
should be displayed only when a particular audio 25 
object in the audio sequence is played back, 

the playback method comprising: 
a playback step for playing back audio objects 
in the audio sequence one at a time in order; 30 
a display step for displaying the at least one still 
image object specified by the first pointer infor- 
mation throughout playback of the audio 
objects in the audio sequence; and 
a control step for having the display step dis- 35 
play the at least one still image object specified 
by a piece of second pointer information 
throughout playback of a particular audio 
object corresponding to the piece of second 
pointer information. 40 

14. A playback method according to Claim 13, 

wherein the control step has the display step 
display a combined image produced by combining 
the at least one still image object specified by the 45 
piece of second pointer information with the at least 
one still image object specified by the first pointer 
information. 

15. A recording method for a semiconductor memory so 
card that stores a plurality of still image objects and 

an audio sequence including a plurality of audio 
objects, 

the recording method comprising: 55 
an assigning step for assigning to the audio 
sequence at least one still image object that is 
to be displayed throughout playback of the plu- 
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FIG. 11A 



MPEG2-AAC format 



format 


Audio_Data_'lransport_Stream(ADTS) 


Profile 


Low UomplexirylLC) protilelmandatory) j 


bitrate per channel" 


between lbkblt/s(mtn.jand V2kbit/s(max.) 
Other bitrates are optional. 


samplingjrequency 


48kHz(mandatoryJ 
44.1 kHz(mandatory) 
32 kHz(mandatory) 
24 kHz(mandatory) 
22.05 kHz(mandatory) 
16 kHz(mandatory) 


channel_coniiguration 


singlej:hannel_eIement(mandatory) 
channel_pair_element(mandatory) 


number j)tjiataj>iocKsjnjrame 


1 header/ 1 raw_aata_oiockimandatoryj 1 


FIG. 1 IB w n 

MPEG layer 3 format 


format 


MPEG-1 layer 3 

MPEG-2 layer 3 low sampling frequency 


bitrate per channel* * 


MVOi l:between lbkbit/s and 9bkbit/s 
MPEG 2 LSF.between 16kbit/s and 80kbit/s 
Other bitrates and variable bitrate are optional. 
Bitrate index "0000" .i.e. "free format" is not supported. 
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48 kHz 
44.1 kHz 
32 kHz 
24 kHz 
22.05 kHz 
16 kHz 


mode 


stereo 

joint_stereo 
single_cannel 


FIG. 11C Windows Media Audio format 


format 


Windows Media Audio format 


bitrate per channel" 


between 8kbit/s and 80kbit/s 
Other bitrates are optional. 
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44.1kHz 
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mode 
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CALCULATED BY REFERRING TO THE TKTMSRT 
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AOB_ELEMENT#x DETECTED FROM FIRST 
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,S34 



S35 



| AOB JRAMEfx OUTPUTTED TO THE DESCRAMBLER1 



,S36 



playjime - playjime +PLAYBACK PERIOD OF AOB.FRAMEfx 
playjata - playjata + DATA LENGTH OF AOB_FRAME#x 



NEXT AOB.FRAME DETECTED FROM ADTS 
HEADER OF AOB FRAMED 



,S38 



I #x<-#x+l Y 

, I \ 
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playjiaia -olav data + d (0 
WHERE f(0: NUMBER OF FRAMES CORRESPONDING TO INTERMITTENT PAYBACK PERIOD 
dh): AMOUNT OF DATA CORRESPONDING TO INTERMITTENT PLAYBACK PERIOD 



S63 



OEMENTEDAOB FRAME* 
COMPARED WITH TOTAL NtftfBER OF FRAMES 
IN AOB ELEMENTfy. AND JUDGEMENT MADE 
AS TO WHETHER INCREMENTED AOB .FRAME* IS 
IN THE TOTAL NUMBER OF FRAMES IN. 
AOB ELEMENT*)- 



,S64 



,S74 

w US THE USES ^ 
PRESSES A KEY ASIDE 
JROM FORWARD 



DGEMENT AS TO 
WHETHER AN AOB_ELEMENT 
" 'I FOLLOWS AOB ELEMENT 
EXISTS f 

*S 65 

AOB.FRAMEffx — AOB_FRAME#x - (NUMBER I 
OF FRAMES IN AOBJELEMENT#y) I 



No 



J5KIP; 



l~gy 



,S66 



play daQ^-play.data+dJsiip Lime) 
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FIG. 81 



POB010 TrackD (1/4) LYRICS POB026 IMAGE FROM PROMO VIDEO 
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FIG. 85 
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Come here and give me lovin' 
Hit me with your freaky style 
Let's get this love thing goin' ! 
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FIG. 86 



POB010 TrackD (1/4) LYRICS POB046 HOLIDAY SNAP 

FROM EUROPE 



Sophisticated lady 
Come feel my love, my woman 
I'll give you pearls and diamonds 
I'll show you round my world 





Come feel my love, my woman 
/ J J fe>AA 1 

I'll give you pearls and diamonds 
r \ C£1>J4 \ \ \ ' 
I'll show you round my world 
V \\\ > IV V 




IMAGE FORMED BY COMBINING 
POB010 SPECIFIED BY PLI#1 WITH POB046 



140 



EP 1 056 094 A1 




141 



EP 1 056 094 A1 




142 



EP 1 056 094 A1 



04 

w 
Q 
04 
O 

2 
O 

H 
(X 

2 
o 

00 

W 

Q 



C5 
00 

O 
i— i 

(X, 



ttl 

< 

Q 



OQ 

a 
w 

I— < 

2 
ta 
Q 

a 

CQ 

2 



o 

CQ 
O 



2 
o 



8 

CVJ 



CO 

o 

w 

CVJ 



00 

w 

> 
CD 
cvj 



CO 

o 



to 
o 



CO 

CQ 
cvj 



O 



00 

H 

03 
00 



3 




a; 
Si 




p 

c 

o 
u 

c 



2 
o 

On 

O 
O 

o 
CQ 

O — 
a, O 

CQ 
O 
ou 





t 

t t 


✓ 






, / 
. / 

: / 
; / 
1 t 

1 9 


* 

■ / 




nation 


ion#l 




c 

c 

.2 




CO 




•4-* 

co 


Manager In! 
(POBMG 


Count Infon 
(P0BCI#1 




Count Infon 
(P0BCI#r 


POB 


POB 




POB 



05 

VII 
C 

VII 



CQ 
oo 

o 

X 
H 
O 
2 
tu 

Q 

w 
X 



143 




144 



EP 1 056 094 A1 



FIG. 91 
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FIG. 93A 
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